DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOl 
MONTEREY CA 93943-5101 



NAVAL POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



THE DESIGN AND IMPLEMENTATION OF ZTRAX: A TRAINING, 
READINESS AND FLIGHT HOUR RELATIONAL DATABASE 
MANAGEMENT TRACKING SYSTEM 

by 

Richard E. Hodgkins 
March 1992 

Thesis Advisor: Robert L. Knight, LCDR, USN 



Approved for public release; distribution is unlimited 



UNCLASSIFIED 



SECURITY CLASSIFICATION OF THIS PAGE 



REPORT DOCUMENTATION PAGE 


la REPORT SECURITY CLASSIFICATION 
UNCLASSIFIED 


1b RESTRICTIVE MARKINGS 


2a SECURITY CLASSIFICATION AUTHORITY 


3 DISTRIBUTION/AVAILABILITY OF REPORT 
Approved for public release; distribution is unlimited . 


2b DECLASSIFICATION/DOWNGRADING SCHEDULE 


4 PERFORMING ORGANIZATION REPORT NUMBER(S) 


5 MONITORING ORGANIZATION REPORT NUMBER(S) 


6a NAME OF PERFORMING ORGANIZATION 
Naval Postgraduate School 


6b OFFICE SYMBOL 
(If applicable) 

37 


7a NAME OF MONITORING ORGANIZATION 
Naval Postgraduate School 


6c ADDRESS {City, State, and ZIP Code) 
Monterey, CA 93943-6000 


7b ADDRESS {City, State, and ZIP Code) 
Monterey, CA 93943-5000 


8a NAME OF FUNDING/SPONSORING 
ORGANIZATION 


8b OFFICE SYMBOL 
(If applicable) 


9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 



8c ADDRESS {City, State, and ZIP Code) 1 0 SOU RCE OF FUNDING N UMBERS 



Program tlemeni No 


Projtv i No 


IdSK No 1 ( 10,1 ' 


( 

Vision 






| Number 

1 

1 





1 1 TITLE (Include Security Classification) 

THE DESIGN AND IMPLEMENTATION OF ZTRAX; A TRAINING, READINESS AND FLIGHT HOUR RELATIONAL DATABASE 
MANAGEMENT TRACKING SYSTEM 

12 PERSONAL AUTHOR(S) HODGKINS, RICHARD, ECk 



13a TYPE OF REPORT 


13b TIME COVERED 


14 DATE OF REPORT (year, month, day) 


15 PAGE COUNT 


Master’s Thesis 


From To 


92/03/03 


112 



16 SUPPLEMENTARY NOTATION 

The views expressed in this thesis are those ol the author and do not reflect the official policy or position ol the Department of Delense or the U S. 
Government. 



17 COSATI CODES 




18 SUBJECT TERMS (continue on reverse if necessary and identify by block number) 


FIELD 


GROUP 


SUBGROUP 


DESIGN; IMPLEMENTATION; TRAINING, READINESS. FLIGHT HOUR; RELATION AL 








DATABASE MANAGEMENT TRACKING SYSTEM 



19 ABST RACT (continue on reverse if necessary and identify by block number) 




In an era ofdiminishing budgets, information technology must help direct operational commanders in the maximum utilization of their available 
resources. The institution of a relational database management tracking system to identify and exploit an organization’s strengths will aid in 
keeping forces combat ready at all times. The design and implementation of ZTRAX; a training, readiness and flight hour relational database 
tracking system. ZTRAX is expected to provide historical information of home and deployed, operational and training flight evolutions to aid in 
the decision making process of training and readiness planning The ZTRAX application is a menu driven program which permits the adding, 
editing and querying of data contained on two source documents; the Monthly Training and Readiness Report and the Monthly Flight Hour 
Report. ZTRAX is run concurrently from w ithin the main Paradox program to allow r for a vast array of ad hoc queries, reports and the importation 


ol graphical display mechanisms. 






20 DISTRIBUTION/AVAILABILITY OF ABSTRACT 


21 ABSTRACT SECURITY CLASSIFICATION 




Q UNClASSIFltD/UNUMIIlO Q SAMI AS HtPOKI Q] OTIC USEHS 


UNCLASSIFIED 




22a NAME OF RESPONSIBLE INDIVIDUAL 


22b TELEPHONE (Include Area code) 


22c OFFICE SYMBOL 


ROBERT L. KNIGHT, l.CDR, L SN 


408 646-277 1 


as/k t 



DD FORM 1 473, 84 MAR 83 APR edition may be used until exhausted SECURITY CLASSIFICATION OF THIS PAGE 



All other editions are obsolete 



UNCALSSIFIED 



Approved for public release; distribution is unlimited. 



The Design and Implementation of ZTRAX: A Training, Readiness and Flight Hour 
Relational Database Management Tracking System 

by 



Lieutenant, United States Navy 
B.A., Flagler College, 1985 

Submitted in partial fulfillment 
of the requirements for the degree of 

MASTER OF SCIENCE IN INFORMATION SYSTEMS 




from the 



NAVAL POSTGRADUATE SCHOOL 
March 1992 
. / / . / // 




n 



ABSTRACT 



In an era of diminishing budgets, information technology 
must help direct operational commanders in the maximum 
utilization of their available resources. The institution of 
a relational database management system to identify and 
exploit an organization's strengths will aid in keeping forces 
combat ready at all times. The design and implementation of 
ZTRAX; a training, readiness and flight hour relational 
database management system. ZTRAX is expected to provide 
historical information of home and deployed, operational and 
training flight evolutions which will aid in the process of 
training and readiness planning. The ZTRAX application was 
implemented in November, 1991 and is a menu driven program 
which permits the addition, editing and querying of data 
contained on two source documents; the Monthly Training and 
Readiness Report and the Monthly Flight Hour Report. Ztrax is 
run concurrently from within the Paradox program to permit a 
vast array of ad hoc queries, reports and the importation of 
graphical display mechanisms. 
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I . INTRODUCTION 



The fulfillment of the information needs of the U.S. Navy 
is critical to attaining continued tactical superiority above, 
on and below the surface of the oceans. The realization of 
these needs constitutes a variety of scenarios ranging from 
the real-time update of mission critical information to the 
analysis of the training and readiness records of a unit. 
Recent and predicted future reductions in appropriated funding 
magnifies the need for comparative analysis of training and 
readiness at all levels of operational command. To effectively 
and efficiently prepare the Navy for future encounters with 
hostile forces we must employ information technology to supply 
the systems and software able to produce timely and accurate 
information . 

Specific measures of unit training and readiness provide 
the means to evaluate a squadron, airwing or fleet's ability 
to complete its assigned tactical mission. The majority of 
minor commands, i.e., airwings, rely on manual methods to 
extract relevant information from a myriad of data, maintained 
as it is received, in hard copy message format. Answering 
routine queries is often time consuming and frequently 
unsuccessful. This situation can be remedied by the 
implementation of a database management system (DBMS) utilizing 
a user friendly, commercially available relational database 
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software application (RDBMS) . Once the RDBMS is operational, 
specific local user requirements can be identified. There are 
typically several repetitive database queries which will aid 
in the construction or use of a decision support system(DSS) . 
Of vital importance to the users is the ability to attain and 
interpret data and information quickly and efficiently without 
a tedious and time consuming process. This will be accomp- 
lished through the implementation of a DSS. 

A. BACKGROUND 

The mission of a Fleet Patrol Wing is to guide and direct 
the organization, administration, and training of all patrol 
squadron (VP) forces subordinate to it (COMPATWINGSPAC, 1988) . 
Specific responsibilities include: 



• Operational control functions of air Anti-submarine 
warfare (ASW) units assigned to a Fleet Commander. 

• Supervise and coordinate patrol squadron training. 

• Investigate and recommend improvement in ASW training, 
tactical doctrine, and equipments. 

• Establish performance and readiness standards and 
evaluates the readiness of subordinate squadrons. 

• Conducts inspections of patrol wings, stations and 
squadrons . 

• Directs aircraft maintenance practices, procedures and 
doctrine in subordinate squadrons with a view of promoting 
maximum efficiency. 

• Exercises military control of assigned forces in the 
execution of operational ASW and surveillance missions and 
tasks (COMPATWINGSPAC, 1988) . 
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Several departments within the organizational structure of 
an airwing retain functional responsibility for the areas 
listed above. They include: 

• Operations 

• Tactics Development and Evaluation (Tac D&E) 

• Readiness and Training Plans 

• Manpower and Personnel 

• Maintenance 

The departments deriving the majority of the benefit from 
ZTRAX are Operations and Readiness and Training Plans. The 
requirement for timely readiness and training information 
presented in a desirable format is an increasingly difficult 
and time consuming task. Numerous man-hours are spent in 
daily activities to satisfy the current needs. ZTRAX will 
serve to meet the present needs and those of the future. 

1. Readiness and Training Plans Department Operations 
The readiness and training plans department of an 
airwing is a cornerstone to the efficient operations and 
readiness stature of all the squadrons over which it maintains 
operational control. The office serves as a collector of data 
and disseminator of vital information. The numerous readiness, 
training and flight hour concerns range from individual 
squadron queries for comparative mining readiness command 
inspection (MRCI) flight hours, parent airwing requests for 
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graphical portrayals of monthly aircrew manning levels and 
pilot training and proficiency statistics to CNO directed 
monitoring and maintenance of prescribed combat readiness 
levels. Currently, the majority of the training, readiness 
and specific squadron flight hour information is processed 
manually. Gathering pertinent data in these instances is 
extremely difficult and time consuming because they are stored 
in hard copy form and require several iterations of records 
search. Other departmental operations such as airwing- level 
flight hours and OPTAR budgets are tracked utilizing various 
commercial spreadsheet applications. It is essential ZTRAX 
have the ability to interact with those applications. 

a. Structure 

The readiness and training plans department is 
staffed by two personnel, a post -patrol squadron (VP) 
department head tour Commander who serves as the Readiness and 
Training Plans Officer and a Chief Petty Officer. In 
addition, two civilian administrative assistants are available 
for administrative functions, as required. The Readiness 
Officer reports directly to the Admiral's Chief of Staff on 
all matters concerning the department's affairs. 

b. Workload 

The majority of data processed by the readiness 
department is received via message format from the operational 
squadrons or parent organizations, such as COMNAVAIRPAC , where 
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they originate. Flight hour, OPTAR and future detachment and 
deployment activity data pertaining to current records on the 
existing hardware are transferred to the department, 
accordingly. These manual data transfers and subsequent 
(queries account for approximately seventy percent of the daily 
departmental operations. OPTAR updates, tempo of operations 
and various queries demand numerous hours of attention each 
day, primarily due to the inability of the existing 
information system to maintain all of the required data. 
Periodic reports and miscellaneous information services and 
message traffic complete the required departmental activities. 

2. System Evaluation and Functional Requirements 

The existing hardware consists of two Z-248 processors 
with the standard 20 megabyte hard drive, 640Kb of RAM and a 
VGA monitor. These systems utilize of variety of commercially 
available microcomputer spreadsheet and database software 
applications to store and access information. Presently, hard 
drives of both systems are completely filled data required to 
effect daily operations. The constraints of the hard drives 
capacity have necessitated the least recent data being removed 
from memory to allow new data to be entered into the program. 
This has resulted in reports and graphical portrayals of 
information that are incomplete because a portion of the 
historical data had to be removed to accommodate the new data. 
The hardware currently in use would suffice with some upgrades 
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if the processing needs of the department were to remain 
constant, i.e., maintain the status quo of tracking and 
presenting queried readiness and training information via the 
manual means. The introduction of ZTRAX, a training, 
readiness and flight hour tracking system, has drastically 
increased the memory and processor speeds required to most 
effectively and efficiently utilize the designed system to its 
utmost. Several alternatives able to solve the aforementioned 
problems exist: 

1. Upgrade the motherboard to a faster processor capable of 
providing less idle time during query processing. 

2. Augment the existing hard drive with a larger and faster 
model containing a disk cache able to provide sufficient 
memory and fast access into the future. 

3. Expand the random access memory (RAM) from the current 
640Kb to at least two megabyte. This will allow the entire 
ZTRAX program to exist in main memory during database 
operations . 

4. Replace the existing system with a current GSA contract 
model 386 machine which will provide satisfactory 
performance well into the future. 

The most desirable solution, as shown in a comparative 
analysis of options contained in Chapter V, is the purchase of 
two Unisys 386 machines per the current GSA Desktop III 
contract agreement. 

Functional requirements for ZTRAX were based on the 
need to lessen the time required to research and present 
information currently stored in hard copy form, the 
requirement to use the Monthly Training and Readiness Report 
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and Monthly Flight Hour Report as source documents and desired 
end-user functionality. They are as follows: 



1. Safely, securely and reliably maintain data and records. 

2. Provide pre-defined queries of frequently requested data 
fields, i.e. monthly status of pilot/crew training, Primary 
Mission Area(PMA) readiness for individual squadrons and 
parent airwings and comparative analysis of flight hours. 

3. Provide ad hoc query capability without lengthy and 
cumbersome procedures. 

4. Allow graphical interface portrayals with Lotus and 
Harvard Graphics. 

5. Provide for the future capability to update records on- 
line with floppy disks vice the current system of manual 
entry. 

6. Display all text and graphical information with the 
option to produce immediate hard copy. 

B . RESEARCH QUESTIONS 

This thesis will address the following questions: 



1. Can a commercially available relational database software 
application be fully utilized to accomplish RDBMS functions, 
such as ad hoc queries and graphical output portrayals, in 
a fast and efficient manner despite the computer hardware 
constraints held by operational airwings? 

2. What are the specific system requirements for utilizing 
the database management system to maximize its capabilities? 

3 . Can measures be implemented to enter raw training and 
readiness data into the database by other than the manual 
manipulation of the tables themselves? 

4. Can justification be given to replace existing computer 
hardware systems with current Unisys GSA contract models in 
order to meet the desired performance and data storage 
requirements? 
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C . OUTLINE 



Chapter II will detail the design of the RDBMS. 

Chapter III discusses implementation of the RDBMS and its 
interaction with other commercial software applications for 
graphical representation purposes. The users manual is 
contained in Appendix E. 

Chapter IV discusses the issue of computer security and 
its relevance to all microcomputer operations. 

Chapter V provides recommendations and conclusions for the 
use of a relational database management system to provide 
accurate and timely readiness and training information. 

Appendix A-E will provide the data input documents, object 
diagrams, object definitions, domain definitions and the users 
manual, respectfully. 
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II. DESIGN 



Database design involves several significant steps which 
are necessary to ensure that a complete and conceptually 
correct model emerges. Using an object oriented design 
approach, the first step is to identify the database system 
requirements. This includes identifying the objects the users 
require to effectively track their data. Next, the objects 
identified in the requirements phase will be normalized to 
ensure they support the requirements of the users. The 
normalization process gathers data items into relations which 
are not redundant and can be manipulated by the users without 
the threat of data loss due to modification anomalies (Dolan, 
1988) . 

The use of the relational data model for ZTRAX was 
predicated on the conceptual view the user has of the data 
objects contained within the system. The goals of the 
relational model are twofold; to provide data independence by 
identifying the separation of the physical format from the 
users view of the data, and to achieve data integrity by 
avoiding data inconsistencies and anomalies in the processing 
of the data itself (McClanahan, 1991) . 

The view of the system that's provided by the (relational) 
data model describes the structure of the data in a 
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natural form that the users can intuitively understand 
without extensive training (McClanahan, 1991) . 

The users in the readiness and training plans department, 

having little or no experience with database operations, will 

benefit from the architecture of this model. 

A. REQUIREMENTS DEFINITION 

The basis of the design of ZTRAX revolves around two 
monthly reports, the Monthly Training and Readiness Report 
message and the Monthly Flight Hour Report message, depicted 
in Appendix A as source documents. These reports are 
transmitted to the airwing by the originating squadron by no 
later than the fifth day of each month and provide relevant 
data from the previous month's operations. The standardized 
format and fixed field length of the reports will allow for 
future updates of records via floppy disk. The attributes and 
objects identified for ZTRAX are derived from these reports. 

1. Objects 

Objects are defined as a collection of properties that 
describe an entity in the users work environment. All objects 
have a name which corresponds to the entity it represents . 
They can represent items such as an inventory item, an 
operational flight hour category or a monthly readiness 
report. Each object property must represent specific 
characteristics of the real-world entity that is important to 
the users of the database. The object properties must provide 
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a sufficient description of the true entity the users need to 
have represented. An entity is something perceived by the 
user as a single independent unit capable of existing on its 
own. The database is a collection of instances of objects, 
that is a representation of one specific entity (Dolan, 1988) . 

The objects and their respective properties were 
created for ZTRAX through a hybrid design approach. Sample 
source documents, i.e. the Monthly Training and Readiness 
Report and the Monthly Flight Hour Report, and end-user 
requested data input and output displays justified the object 
oriented design by verifying the users view and perception of 
the data entities. End-user involvement during the design 
phase is expected to result in an easing of the initial 
training required to use the database because the users are 
familiar with the objects, their functions and meanings. 
Appendices B, C, and D provide graphical views of the objects, 
object definitions and domain definitions, respectively. 



1. DETOPS Object represents the detachment operations during 
a report month and pertains to both source documents. This 
object provides the detachment name, site and type, dates of 
detachment, total flight hours, number of aircraft, aircrews 
and days. The objects ID and a subset of the multiple 
valued FLTHRS object, category, are also contained in 
DETOPS . 

2. FLTHRS Object represents the various types of flights and 
flight hours performed by an operational squadron. It 
provides a category name, area name, type name, and specific 
type as they pertain to both source documents. The objects 
ID and MATRIX are included within FLTHRS . 
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3. FLTRPT Object represents the monthly flight hour report 
source document shown in Appendix A. It contains the ID 
object, the multiple valued FLTHRS object, the PILOT STATS 
object, the multiple valued INST PILOTS object and the 
multiple valued DETOPS object. 

4. ID Object represents the key identifying attributes of 
the database. They are: squadron number which identifies a 
specific squadron, month which identifies the report month, 
year, report type which identifies the source document where 
the data originates and squadron status which indicates 
whether the squadron is home or deployed during the report 
month. 

5. INST PILOT Object represents instructor pilot data 
contained only on the monthly flight hour report. It 
consists of rank which identifies military rank, date of 
designation as an instructor pilot and predicted rotation 
date of the instructor pilot. The ID object is included 
within INST PILOT. 

6. MANNING Object represents designated aircrew manning 
levels within a squadron for a report month. It is specific 
to the monthly Training and Readiness report . Manning 
consists of: position name which identifies the aircrew 
position, total, gains and losses which give numeric 
indications of the manning levels for a specific position, 
cat I/II or III which categorize officer sea tours and the 
ID object. 

7. MATRIX Object represents various entities relating to 
specific flights and flight hours. This object is specific 
to the monthly Flight Hour report and includes: sorties 
which indicate the number of missions flown for a particular 
category, area, type or specific type, onstation which 
indicates the flight hours onstation during a sortie, total 
flight hours for the mission and contingency which is a 
numeric count of the number of those missions flown. The 
FLTHRS object is included in the MATRIX object. 

8. NIGHTHRS Object represents the night flight hours flown 
by a squadron during a report month and is specific to the 
Training and Readiness report. It contains night hours, 
night hours as a percent of total hours and the ID object. 

9. PILOT STATS Object represents first tour pilot statistics 
and is specific to the Flight Hour report. It contains the 
average first pilot time for first tour pilots, number of 
pilots not acquiring ten hours of first pilot time and PEF 
pilots. The ID object is also represented. 
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10. RDYRPT Object represents the monthly Training and 
Readiness report and is comprised solely of the following 
objects: ID, multiple valued MANNING, multiple valued R- 
LEVELS, multiple valued FLTHRS, multiple valued DETOPS and 
NIGHTHRS . 

11. R-LEVELS Object represents the combat readiness levels 
attained by a squadron's aircrews, in various categories, 
during the report month. R-LEVELS is specific to the 
monthly Training and Readiness report and contains primary 
mission area(PMA) names, C- rating which is an assigned 
rating for a PMA dependent upon the number of aircrews in a 
squadron designated as combat ready, number of aircrews 
designed C-l(the highest level) and the percentage of crews 
rated C-l to the total number of crews in a squadron. The 
ID object is also contained with this object. 



Each of the above objects is essential to accurately 
represent the users view of the data in a relational database 
model. It was possible in some instances however, to utilize 
a single object to represent duplicate data contained in both 
reports, thereby eliminating any data redundancy. The DETOPS 
Object and FLTHRS Object reflect similar data found in both 
source documents. An attribute of the ID Object, report type, 
will insure proper identification and placement of similar 
data elements found in these two objects. 

2 . Functional Components 

The functional components of a database include the 
flow of data and information and the necessary update, display 
and control mechanisms which keep the database information 
current and accessible. 

The ZTRAX tracking application is a simple model of 
data flow and retrieval. All input data is received by the 
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Training and Readiness Plans department via message from 
operational squadrons. The format and guidance for the 
monthly messages are two airwing originated instructions, 
COMPATWINGSPAC 3500.1 AND COMPATWINGSPAC 3500. 2 7A. Upon 
receipt of the monthly Training and Readiness and Flight Hour 
messages, department personnel enter all the data contained on 
them into the database. Reports and graphic depictions of 
data are generated as required in response to ad hoc queries 
made by the department, squadrons, Chief of Staff or Admiral. 
Presently, the department is not required to submit any 
recurring reports that contain data which will originate from 
the ZTRAX database tables. The implementation of ZTRAX will 
provide the users the capability to do so in the future. 

B. NORMALIZATION 

Normalization involves the gathering of data items or 
properties into relations. Objects are used in the 
normalization process because they represent groups or related 
data items. The goal of normalization is to provide a 
representation of the user defined objects in the database by 
using relations that provide the necessary data to construct 
the user objects and are able to allow rows of data to be 
inserted, deleted or modified without inconsistencies or 
errors resulting (Dolan, 1988) . 

The first step in the normalization process is the 
elimination of modification anomalies. They can result in the 
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elimination of existing data in the database, a deletion 
anomaly. The inability to enter a fact about one entity until 
another entity has been entered, an insertion anomaly. ZTRAX 
does not contain either of these anomalies in it's design. 

Relations can be classified by the types and classes of 
anomalies they may contain. The techniques for preventing 
these anomalies are called normal forms and proceed from first 
to fifth. Normal forms identify the relationships among 
attributes, functional dependencies and key fields of the 
relations and seek to resolve the modification anomalies. 
Normalization of the relations is an essential step in the 
logical design of a database. Capturing the user's view is 
essential to the successful design and implementation of a 
relational database management system. Object specifications 
for ZTRAX were defined by completing a thorough systems 
analysis to establish the exact requirements and constraints 
the database must meet. Background information identified the 
smallest useable data elements, known as attributes, and 
grouped them into entities which formed the basis for the 
tables in ZTRAX. This design method has insured ZTRAX will 
provide sharable data and information, assure integrity and 
evolve with the growth of the organization (Bagchi, 1987) . 
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III. IMPLEMENTATION 



Database implementation is an on-going, iterative process. 
It involves much more than the installation of the application 
and user training, rather it is the complete and thorough 
commitment to an adaptive maintenance plan which involves 
database administration guidelines, back-up and recovery- 
procedures, database housekeeping and future enhancement 
considerations . 

A. INSTALLATION 

The installation procedures for ZTRAX are quick and simple 
to accomplish. Because ZTRAX runs best from within Paradox, 
the first step is to create a subdirectory named ZTRAX. Next 
make a back-up copy of each ZTRAX program disk. Store the 
original ZTRAX disks in a safe place and continue with the 
installation process using the back-up copies. To continue, 
insert ZTRAX disk one into the A drive and copy the entire 
contents into the ZTRAX subdirectory of the hard drive. 
Repeat this step for the remainder of the ZTRAX disks. ZTRAX 
is now installed on the system. To initiate ZTRAX, use normal 
start up procedures for Paradox. When the Paradox main menu 
appears, select TOOLS and change the directory to ZTRAX. This 
allows the standard query, report and graphic functions of 
Paradox to be used by the ZTRAX tables without changing 
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directories later. Now you can run the ZTRAX application 
through Paradox by selecting the SCRIPT/PLAY option of the 
main menu and entering ZTRAX at the prompt. At this point the 
ZTRAX main menu will appear and data entry, edit or view 
(query) are selectable. The specific use of these ZTRAX 
options are contained in the users manual (Appendix F) . To 
maximize the capabilities of ZTRAX, all users of this appli- 
cation should be familiar with standard Paradox operations. 

B . TRAINING 

An operator training program for ZTRAX should accompany an 
on-going program designed to maximize the potential uses of 
Paradox. As a stand alone application ZTRAX successfully 
accomplishes its designed task, to provide a repository of 
readiness and flight hour data which is easily accessible and 
manipulable. However, optimizing the data contained in ZTRAX 
is best accomplished with ad hoc queries through the use of 
Paradox and its multiple functions. For users to excel at 
using ZTRAX, they must first feel comfortable in the Paradox 
operating environment. User training in Paradox can be 
obtained many ways. First, Paradox offers an extremely 
thorough and instructive help menu which is accessible from 
any Paradox screen at any time. These help tips and screens 
benefit all levels of users by explaining keystrokes, query 
forms, reports, etc., then showing examples of the proper 
format for the command in question. Second, Paradox offers an 
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on-line tutorial program designed to teach basic database 
operations to the inexperienced user. It contains a program 
which walks new users, step by step, through creating, 
editing, printing and querying tables. The use of this 
tutorial is essential for first time users of Paradox. It 
will provide the necessary baseline of knowledge required to 
utilize Paradox for effective database operations. 

Training in the use of the ZTRAX application should occur 
after a working knowledge of Paradox techniques have been 
obtained. The ZTRAX program is completely menu driven with 
explanations of each screen display located below various menu 
choices. The most effective training method for learning 
ZTRAX is hands on experience with the menu system. All of the 
menus and screen displays are similar to the source documents 
they represent to ease the initial training required for first 
time users of the program. Although knowledge of Paradox is 
necessary to fully utilize ZTRAX, a user unfamiliar with 
Paradox or ZTRAX could enter new data with very little 
training. This an important future consideration for ZTRAX 
because its use in a squadron environment will not allow for 
extensive user training prior to implementation. Data 
add/edit procedures in their present form will allow junior 
enlisted squadron personnel to enter data with a small amount 
of training. This serves an important purpose by freeing 
senior personnel from the time intensive burden of data 
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entry/edit and allows them the freedom to query the database 
based on their needs. 

C. DATABASE ADMINISTRATION 

Administrative control of the database will be under the 
direction of the Readiness and Training Plans Officer. His 
responsibilities currently include maintaining hard copy of 
the data and providing information drawn from it. Therefore, 
as department head, he has the greatest interest in duties 
which would normally be performed by a database administrator 
(DBA) for this application. The duties of a DBA are wide and 
varied, dependent upon the size and type of database 
application that is being run. For ZTRAX, the necessary 
administrative tasks are very specific because it is a 
relatively small application. 

The first priority of the DBA (department head) for ZTRAX 
is the security of the database and the system which contains 
it. The two microcomputers located in the department exist at 
the present time with no physical security devices to prohibit 
entry into the system. A security plan including physical and 
data security measures must be instituted to preserve the 
integrity of the system and database, should an intrusion 
occur. The plan should be clear and concise as to which users 
are authorized access and where they are allowed to travel 
once logged on to the system. Chapter IV provides a security 
site survey of the department and makes specific 
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recommendations for the initiation of a security program for 
the ZTRAX database and the department's Z-248 computers it is 
currently run on. 

The second priority of the DBA is the assurance that the 
users are receiving the information they require. This is 
accomplished two ways. First, a periodic review of the source 
documents will identify any changes in the necessary input 
data. If a change does occur, it will be the responsibility 
of the DBA to modify the input, edit and pre- defined query 
screens found in ZTRAX. These procedures are given in the 
maintenance section of the ZTRAX users manual. Second, 
determining if users are receiving the information and support 
they require. If they are not, training with Paradox and the 
specific functions the users require can alleviate their 
dissatisfaction and provide new avenues to more effective and 
efficient use. In this instance the DBA must recognize the 
need for greater user involvement. 

The third priority of the DBA is the management and 
allocation of disk space used by the ZTRAX database tables and 
related files. As it stands, the ZTRAX program accounts for 
1 . 8 megabytes of memory usage on the hard drive . Each Monthly 
Training and Readiness report record takes up approximately 
500 bytes of memory and a Monthly Flight Hour Report about 
1500 bytes. This total of 2000 bytes, or 2Kb, accounts for 
one squadron's data input for a month. For the nine squadrons 
under the operational control of the airwing the total monthly 
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data input to ZTRAX and stored on the hard drive, about 18Kb. 
By today's standards, this is a small amount of disk space to 
be concerned with, however, the hardware constraints on the 
existing microcomputers at the airwing make this a serious 
problem. 

The microcomputers in the department are Z-248's with 20 
megabyte hard disks. When ZTRAX was installed the available 
hard disk capacity dropped to below one megabyte. That 
translates to four years of input data assuming no other data 
is stored from any of the various spreadsheet and word 
processing programs existing on the same computer. 

First, how much historical data is required to provide an 
accurate picture of training, readiness and flight hour 
statistics for a squadron or airwing? At the present time, 
the department maintains copies of all the monthly reports 
from all the squadrons for a period of three years following 
its transmittal. With the current situation of available 
memory, three years of data would take approximately 650Kb of 
space, effectively filling the hard disk to capacity without 
room for any other data storage. Two years of data would, 
however, provide an entire 18 month operating cycle for a 
squadron plus six months overlap for any contingencies. This 
18 month training/deployment cycle is the basis for the data 
analysis of the optimal training and readiness posture done in 
the department . 
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If a constant historical record of the two previous years 
is to be maintained on the hard disk, then older records must 
be archived prior to deletion. Archiving the data allows more 
working space on the hard disk and provides several years of 
historical data. If the requirement for historical data 
arises, the archived data can be loaded into a floppy drive 
and queried without reloading to the hard disk. The best way 
to archive is to copy specific records to floppy disk as they 
are entered as new data. This prevents accidental deletions 
two years from now when the data is to be deleted and provides 
an additional backup copy of the database records. The use of 
the Paradox copy command provides the means to copy data 
record by record, which is required here. The ZTRAX users 
manual describes the use of this command for disk backup 
procedures, any further reference to the copy function is 
contained in the Paradox users manual. 

Consistent with the memory management problem experienced 
with ZTRAX records is the lack of archiving and backup records 
for the various other applications contained on the 
department's computers. Although beyond the scope of this 
thesis, an internal evaluation of the historical record 
storage requirements for each application should be made to 
identify possible solutions to this problem. 

Backup and recovery procedures are an integral part of 
any database administration plan. The ability to recover 
sensitive data in the event of system failure can save 
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hundreds of hours attempting to manually recover lost records. 
The department's information system consists of two stand 
alone microcomputers which operate solely in a transaction 
processing mode. For this reason, data and record backup 
procedures should be instituted following every new data entry 
and edit. This will ensure a backup disk library which always 
contains newly added data and records. Procedures for backup 
and recovery are contained in section one of the ZTRAX users 
manual and make use of the Paradox copy command. 

Database housekeeping is another duty of the DBA. It 
involves a variety of routine maintenance tasks which keep the 
system operational and accessible. Users in particular 
benefit from a housekeeping program which is attentive to 
their needs. Several of the activities already discussed, 
such as backup and archive copies of data, updating program 
files and persistent user training all comprise an effective 
data housekeeping plan. The following section describes 
another important DBA function, future considerations and 
updates for the ZTRAX application. 
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D. FUTURE PROGRAM CONSIDERATIONS 



As essential to maintaining prograin integrity by making 
backup and archive copies of disks is the continuing program 
of perfective maintenance for data entry, edit and query. 
Perfective maintenance involves the redefinition of tables, 
screens, input and output displays. As the ZTRAX application 
becomes more familiar to users they will progressively request 
more from it. The manipulation of the Paradox program can 
answer many of these requests, primarily from the standpoint 
of ad hoc queries, but data add and edit is a ZTRAX function. 

There are two situations where a change to the ZTRAX 
tables and associated input/edit screens would be necessary. 
First, a change to the source documents would require an 
amendment to the tables. Second, user requests for modified 
data entry screens and forms. Both instances are covered in 
section six of the ZTRAX users manual (Appendix F) . 

The largest concern relative to these two situations 
described above is changing the fields in a table and hence 
their format. If a new field is added to a table, the 
associated input form must also have that field added to it or 
there will be no way to add the data from the new field into 
ZTRAX. This is a simple procedure which is described, with an 
example, in section six of the users manual. Changing the 
format of the table also affects the archive procedure already 
discussed. To use the Paradox add command to archive records 
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the tables must be of compatible format. In order to preserve 
the older records and save the new ones it will be necessary 
to create a new archive file for the newly formatted table. 
Queries of archived historical data using the floppy drives 
will still be possible, only slower because Paradox will be 
required to search multiple files for data instead of one. 

Modifying input, edit and query screens for the purpose of 
user satisfaction is also covered in section six of the users 
manual. These procedures, however, have no effect on the 
existing structure of the tables. Therefore, archiving can 
take place normally. Paradox also offers several utilities 
which allow the user to customize the Paradox application 
based on their needs. Screen colors, default directories, 
protected tables and several others are available for use and 
manipulation by the DBA. The Paradox users manual is an 
excellent source of knowledge for the various utilities 
available and their requirements. 

Another future consideration for ZTRAX is the automatic 
update of the database tables with floppy disk file transfer, 
vice the current method of manual entry. Paradox offers a 
unique utility designed to address this situation. FLIMPORT, 
as Paradox refers to the it, creates or updates tables from 
fixed-length ASCII format records. This utility is signifi- 
cant because it can transfer files either singly or in a batch 
processing mode. The files from the floppy disk are first 
copied into an import specification file designed to represent 
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the table. Next, the specification file transfers the new 
data fields into the appropriate ZTRAX table. The activation 
of this utility would divert the time required to manually 
enter the new data in ZTRAX to other activities and suspend 
any requirement to correct errors in the database caused by 
human data entry error. 

To take advantage of the capabilities of the FLIMPORT 
utility, the local communications center would be required to 
place a Monthly Training and Readiness Report or Flight Hour 
Report message for each squadron onto a floppy disk. The 
message would already be formatted in fixed- length ASCII 
characters, therefore no file conversion would be required. 
The communications center need only to place the two different 
messages in separate directories on the disk. The files for 
each type of message would be identified by squadron number. 
When the hard copy messages are delivered to the airwing the 
floppy disk could be delivered as well. The capability 
currently exists at some communications centers to deliver 
messages on floppy disk in a fixed field length ASCII format, 
unfortunately, it is not a standardized procedure and subject 
to special circumstances. Further information on FLIMPORT is 
available in the Paradox users manual and in section seven of 
the ZTRAX users manual . 
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IV. SECURITY 



Microcomputer security measures are essential to control 
and insure the integrity of the database. From the standpoint 
of national security, any information system such as ZTRAX, 
used to store or process data that is classified presents a 
potential risk. There are several methods to effectively 
manage the security of a system and its components. 
Personnel, data, software, and hardware controls can all be 
implemented to reduce the risks associated with any operating 
environment . 

Regardless of any protective measures in place, the 
key element to security in any microcomputer 
environment is the user and how well the user follows 
the established computer security policies and 
guidelines. It cannot be overemphasized that users 
are the ones who help to ensure that the environment 
is as secure as necessary (NAVCOMTELSTA, 1991) . 

Database security violations are defined as unauthorized 

access, modifications, readings or destruction of data or 

information. Threats, either malicious or accidental, to the 

system can occur both overtly and covertly. The following are 

security threats to the various entities of a database 

environment (NCTAMS LANT 1991) . 



1. Database - Unauthorized access, Copying, Theft, 
Destruction 

2. Hardware - Failure of protection mechanisms, 
Contributions to software failure 
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3. Systems Software - Failure of protection mechanisms. 
Information leakage 

4. Operator - Duplication of reports, Theft of classified 
material, Fraudulent identification and input (NCTAMS LANT 
1991) . 

There are no entities involving the database and system 
components that preclude the use of security controls to 
maintain system integrity. 

A. BACKGROUND 

SECNAVINST 5239.2 delineates the objectives for the 
Department of the Navy Automated Information System (AIS) 
security program. They include: 

• Preventing fraud and abuse by implementing the necessary 
personnel, hardware, software and data controls 

• Ensuring the availability of reliable information/ 
automated support 

• Protecting AIS resources from damage, misuse and theft 

• Accrediting and triennially reviewing all AIS through a 
comprehensive program supported by certification and risk 
management (NCTAMS LANT, 1991) . 

Of the above objectives, an initial assessment of the risks 
involved with the local operating environment are the first 
priority. Risk management is a process involving the 
identification, measurement and minimization of undesirable 
events which affect all AIS resources. It's purpose is the 
reduction of system risk to the lowest level of practicality 
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and cost effectiveness while consistently remaining within 
mission criticality requirements (NCTAMS LANT, 1991) . 

The DON risk management process involves several distinct 
elements, all of which are necessary to complete an accurate 
evaluation of a commands AIS risks. The elements of the risk 
management process are: 



• AIS Security Survey - Collecting basic information to 
assess existing security posture 

• Activity AIS Security Plan - Planning for security program 
implementation 

• Risk Analysis - Analyzing, quantifying and counter risks 
which pertain to the local activity 

• Contingency Plan - Planning for disaster recovery 

• Security Test and Evaluation - Testing the effectiveness 
of an activity's security program 

• Accreditation Report - Compilation of accreditation 
documentation in satisfaction of local and DON guidelines 
(NCTAMS LANT, 1991) . 



These elements pertain to all types of AIS and include word 
processors, weapon control, communications and pertinent to 
this thesis, microcomputers. 



B . MICROCOMPUTER SECURITY 

Security concerns in a non- complex microcomputer operating 
environment are wide and varied. Data, hardware, software and 
general concerns provide a combination of effectual methods to 
control access and insure a stable and safe AIS work space. 
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1. Data Concerns 



Data concerns relate to data as a single entity, 
independent of storage media on a microcomputer. Access to 
the data is the single most important consideration regarding 
security. Data access controls are accomplished several ways, 
the most frequent being password protection. Within the 
confines of a database environment, a hierarchical structure 
of passwords can be used to help control authorized and 
prevent unauthorized access. 

Other data concerns are the nature of the data and the 
media protection afforded that data. Obviously, classified 
data should only be accessible to those authorized users with 
the proper security clearance and the need to know. Ensuring 
the proper marking, declassification and destruction of 
magnetic storage media will prevent any security violations 
from occurring. 

2 . Hardware Concerns 

In the microcomputer operating arena, the hardware in 
existence today does not contain the built-in capability to 
provide internal security mechanisms. The theft of microcom- 
puters, with the data on the hard disks still intact, is a 
burgeoning criminal activity in both civilian businesses and 
government agencies. Denying the physical access to micro- 
computers to anyone except authorized users can help prevent 
this crime from occurring. Measures to secure the machines in 
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place also provide a high degree of protection. Using locking 
cables to attach microcomputer bodies to desks or walls, 
storing all removable magnetic media devices, such as external 
hard drives, in safes or locked cabinets and locking all 
offices where microcomputers are contained can all deter an 
attempted theft or system violation. 

3. Software Concerns 

Operating system and software application controls are 
the best way to deter physical access to restricted data. 
Several threats exist that can destroy the operating 
environment. Software attacks by hackers and intruders 
installing virus infections, software piracy and modifications 
to existing systems and data can all suspend your ability to 
operate until the system is purged of any foreign material. 

Password protection is a viable, yet partial solution 
to the software security dilemma. It is available on DOS 
version 5.0, WordPerfect, Paradox and several other commer- 
cially available microcomputer software applications which are 
used by various agencies and commands in the Navy. Passwords, 
if used only at the entry level of the operating system, can 
help provide the necessary means to help prevent software 
security incidents and accidents from occurring. Encryption 
of data and files is another effective method to prevent 
unauthorized access. When used in conjunction with password 
protected files, data encryption provides a higher level of 
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security and access restriction to the operating environment. 

4 . General Concerns 

Microcomputer use is expanding at an exponential rate. 
More users, more applications, more chances for fraud, theft, 
damage and loss to occur. One of the most serious problems 
facing the micro environment is the lack of control and policy 
regarding security and risk management. Continuous user and 
administrator education and training must be implemented at 
all levels of concern. The cost is inconsequential when 
compared to the loss of classified or sensitive data relevant 
to national security. 

C. SITE SECURITY ISSUES 

The ZTRAX tables will contain CONFIDENTIAL data once the 
application has been implemented at the site. It is primarily 
for this reason, the classified nature of the data, that 
security measures must be taken to avoid any undue risks of 
compromising the integrity of the database. Contained on the 
same microcomputer are various other spreadsheet and word 
processing applications that may, at times, contain documents 
or files at various levels of classifications ranging from 
UNCLASSIFIED to SECRET. The intention of this section is to 
expose any possible database and microcomputer security risks 
and prescribe recommendations to solve the problems at hand. 

Physical access to the microcomputers in the Readiness and 
Training Plans Department are limited only by the access to 
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the building which it occupies. However, uniformed and 
civilian personnel unfamiliar to the airwing staff and 
employees are challenged upon entering any office or work 
space. The building is manned twenty- four hours a day and 
access is restricted during off-duty hours. While the access 
to hardware and equipment appears difficult for intruders, 
many instances of theft, destruction or tampering often 
involve personnel familiar to the command. For this reason, 
averting the physical access risks must not be ignored. 

A survey of the current situation would show that few 
physical security measures are in place. During off-duty 
hours the micro- computers in the department are particularly 
vulnerable to intrusion and theft. The introduction of a risk 
counter-measures program should begin with acknowledgement 
that nothing in the department is safe until it is secured. 
The first step of the risk counter-measures plan should be to 
physically secure all hardware and peripheral equipment to 
something either stationary or requiring great difficulty to 
move. For instance, the monitors can be secured with locking 
stranded cables to the computer case, the desk or a wall 
fitted with a cable locking device. This will significantly 
reduce the threat of theft in the department. 

The second step of reducing physical risk involves access 
to the operating system and applications contained on the 
computer. Password protection is a necessary element of any 
file management or program application when it involves 
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classified data. The current operating system, DOS ver. 5.0, 
allows for the use of password protected files, however it 
cannot prevent the use and manipulation of the operating 
system. Other applications found on the computers in the 
department all possess some sort of password protection for 
their files. Paradox can password protect the tables that 
contain the data and ZTRAX can prevent access to the 
application by preventing data entry or edit without a proper 
password. 

It is obvious there is a problem with so many password 
protected files and applications. How many files should you 
protect? To correctly, i.e., change passwords every 90 days, 
maintain a system with this many required passwords would be 
a huge undertaking and administrative nightmare. It is 
therefore recommended that a security software package be 
purchased for the existing system. Most microcomputer 
security software can provide the same functionality as 
passwords can with the benefit of only one password per user. 
A security system of this sort also provides many benefits 
beyond multi-level access protection. Reports of user log-on 



and log-off 


times and 


discrete audit trails are 


two 


major 


benefits . 


Perhaps 


the greatest 


benefit is 


the 


sole 


responsibility for 


appropriate 


access to 


files 


and 


applications 


rests with the system 


administrator (SA) . 


In 



reality, access responsibility is already a function of the 
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SA, in this case the department head, but now access to the 
system is steadfast and controllable. 

The third step of any security program is data protection. 
This is a twofold problem. First, data on the computer must 
be protected, and second, backup data on floppy disk must be 
protected. The relative risks in this department situation 
involve data stored on the computer. Backup disks are all 
secured in a combination locked filing cabinet which is 
accessible only by the department head. Several software 
applications provide functions which prohibit the editing of 
data without proper access or display warnings explaining the 
consequences of such edits. A software security package can 
also provide some measures of control in regards to data edits 
by restricting users to certain functions of file and database 
operations that can prevent unauthorized edits from occurring. 
Another function of security software is the encryption of 
data files. This is an enormous benefit to the security of 
the data because if a user or intruder was somehow able to get 
through the password protection and into the file manager of 
the operating system the files would all be encrypted and thus 
useless as a source of information. 

The above illustrate several elements of risk found in the 
Readiness and Training Plans department. These risks occur in 
a wide range of commands within the Navy and must be 
recognized in order to be dealt with in an appropriate manner. 
Aside from physically restraining hardware and peripherals. 
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the single most effective security measure available is the 
institution of a microcomputer security software application 
which provides password protection, audit trails, file 
management tools and data encryption capability. 

D . RECOMMENDATIONS 

Safeguarding non- complex microcomputer environments 
involves a variety of measures which can be easily initiated 
and maintained. The first step is completing a security 
survey and risk analysis profile of the organization. 
Available from the NAVTELCOMSTA Jacksonville, Florida is the 
"Microcomputer Security Survey and Microcomputer Baseline 
Security Controls Risk Analysis Alternative". This document 
is a tool to gather various system information and address any 
risk associated with the current operating environment. 
Divided into two parts, part one is a survey form which 
gathers the necessary system information. Part two describes 
the "baseline approach" used to identify and manage associated 
risks. Upon completion of the survey, several controls may be 
recommended to minimize, counter or prevent the threat of 
accidents, human errors, physical and environmental controls 
(NAVCOMTELSTA, 1991) . 

1. Safeguarding Data 

Implementing data protection safeguards are an 
essential element of a total security plan. Administrative 



items, such as periodically reviewing the list of authorized 
users, the microcomputers and applications they are cleared on 
and changing passwords regularly can prevent data loss. 
Several software vendors offer a variety of inexpensive 
programs which can provide password protection and encryption 
for files, audit trails and operating system level data and 
access controls. Several other suggestions are obvious but 
often ignored. Keeping unneeded sensitive data off the 
machines and disguising the names of those files that are 
present lessens the possibility of an incident or accident. 
Encryption and periodic purge of outdated files is another 
method providing good security. Access controls for software 
applications provide an outstanding means to not only deter 
intruders but can also provide audit trails of attempted 
unauthorized access. While all methods are not appropriate 
for all operating environments it is essential that some sort 
of data controls be implemented (NCTAMS LANT, 1991) . 

2. Physical Access Protection 

Physical access protection means providing a secure 
area in which to operate and store microcomputer devices, data 
and peripheral equipment. Securing an area through the use of 
combination cipher locks on doors or by restricting access to 
certain areas of the building are reliable methods of access 
denial . Equipment safeguards such as a lock down apparatus 
and power switch protectors can also deter intruders from 



37 



gaining any valuable material from the work space. Physical 
access protection is the most visible and overt deterrent to 
attempted security ministrations. They should be implemented 
in all microcomputer environments (NCTAMS LANT, 1991) . 

In this information age of escalating computer fraud 
and theft, system integrity and security should not be 
sacrificed for any reason. Inexpensive, reliable software 
protection is readily available from a multitude of vendors. 
Several DOD, SECNAV and OPNAV instructions relating to the 
operational security of AIS elements prove it is an issue 
worthy of vital concern. 



38 



V. 



CONCLUSIONS and RECOMMENDATIONS 



The installation and use of the ZTRAX relational database 
tracking system has made a significant positive impact on the 
daily operations of the Readiness and Training Plans 
Department since its inception in November 1991. The ability 
to query information through the use of an RDBMS, vice the 
previous method of manually researching and preparing data, is 
providing the users a greater understanding of training and 
readiness trends for individual squadrons and the entire 
organization. Information such as this will lead to the 
eventual development of optimal training and deployment cycles 
for operational squadrons and airwings. 

ZTRAX is providing a vast array of information which was 
previously difficult to obtain. However, there are several 
drawbacks to using the department's Z-248 microcomputers. The 
first and most noticeable is the speed at which the processor 
operates. Benchmark times of an 80286 processor running at 
8MHz for single queries exceed 1 minute and multiple queries 
exceed 1 minute 45 seconds as compared to an 80386 running at 
20 MHZ which was below 20 seconds for single queries and below 
30 seconds for multiple queries. Several factors contribute 
to the query benchmarks shown above. The 80286 chip is by no 
means state of the art and the majority of todays leading edge 
software applications, such as Paradox, are designed to run on 
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faster machines. The RAM available on a Z-284 is 640Kb. 
Because ZTRAX is most effectively run through Paradox to 
utilize many of its local functions, the program has to 
continually access the hard disk for data. This hard disk is 
currently 95 percent filled with various records of historical 
flight hour and readiness data not related to ZTRAX or 
Paradox, thereby making access times extremely slow. 

There are three alternatives to this situation: 



1. Maintain the status quo. This alternative is not 
recommended based on the expected growth of the use of the 
ZTRAX application and the current idle time experienced by 
users waiting for query results and report displays. 

2. Upgrade the existing system with a new processor, hard 
disk and expanded RAM. GSA Companion Contract N66032-91-D- 
002 provides for Z-248 upgrades that are offered by Zenith. 
The cost of an upgrade to an 80386DX processor running at 
25MHz with 4 megabytes of RAM on the motherboard and a 44 
megabyte hard disk is $1663, plus labor to install. This 
alternative is not recommended because this option is 
essentially replacing 70 percent of the component parts of 
a Z-248 for 80 percent of the cost of a completely new 
system. The departments Z-248 's have been in operation over 
six years and the parts that are replaced with this upgrade 
must be considered for replacement in the near future. 

3. The purchase of a new 80386 machine with a 168 megabyte 
hard disk, 4 megabytes of RAM, VGA monitor and associated 
software and components per the current GSA Desktop III 
contract, number F01620-90-D- 0001 . This system not only 
solves existing problems with processor speeds and hard disk 
capacity but will meet the future needs of establishing a 
Decision Support System with the ZTRAX database tables. 
This desktop model, SLIN 0034AB, is priced at $2103. 
Considering the anticipated problems with extending the 
useful life through upgrades of the Z-284' s, this is the 
most viable solution. 



The purchase of two new microcomputers for the department 
will significantly increase the speed and quality of output. 
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Although the new machines will not affect input methods for 
data entry, the ability to install the complete Paradox 
program on the hard disk will enable the use of the FLIMPORT 
utility. This utility imports data from fixed- length ASCII 
formatted files into the ZTRAX database tables through a named 
specification file. If the ability to receive the monthly 
Training and Readiness and Flight Hour messages from the local 
communications center on floppy disk in the required ASCII 
format were present, FLIMPORT would eliminate all the time 
currently required for data entry. 

The success of ZTRAX operations within the department is 
overshadowed by the lack of security for the integrity of the 
database program, its data and the data of associated applica- 
tions contained on the same microcomputer. Both machines in 
the department have been TEMPOS approved for classified 
information, yet neither use any of the available security 
measures recommended in Chapter IV. WATCHDOG Version 6.0 is 
a security system that provides access control, data and file 
protection, transparent data encryption, virus protection, 
audit trail facilities, system administration and a fixed disk 
management system. All of these features are necessary com- 
ponents of a thorough and complete microcomputer security 
system which will help to guarantee system integrity. This 
software is available under GSA contract number GS00K91AGS5038 
from Government Technology Services, Inc. under GTSI Part 
Nun±>er 298-001-019. 
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This thesis has presented the functional requirements, 
design and implementation of ZTRAX: an RDBMS for tracking and 
evaluating squadron training, readiness and flight hour data. 
An evaluation of the existing information system and its 
ability to fully utilize the functions of ZTRAX and Paradox 
was also discussed. Recommendations were made as to the most 
beneficial steps to take to ensure the maximum capabilities of 
the RDBMS are met and the integrity of the data remains 
secure. The need for this application is the requirement for 
the maximum utilization of training combat ready aircrews in 
an era of diminishing appropriated funding for that purpose. 
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APPENDIX A. SOURCE DOCUMENTS 

COMPATWINGSPACINSTR 3500.1 

SAMPLE MONTHLY TRAINING AND READINESS REPORT MESSAGE 
EXAMPLE - CLASSIFICATION MARKS ARE FOR FORMAT ONLY 
FM: PATRON XX 

TO: COMNAVAIRPAC SAN DIEGO CA//3121// 

INFO: COMPATWINGSPAC MOFFETT FIELD CA//50// 

COMPATWING XXX//50// 

CONFIDENTIAL //N03500// 

SUBJ : MONTHLY TRAINING AND READINESS REPORT (U) 



1. 


(C) 


A. PATRON XX 














B. MARCH 


[ 90 














C. N/A 












2 . 


(C) 


A. 33 


B. 


1 


C. 


1 D. 29/3/1 






E. 24 


F. 


0 


G. 


1 H. 21/2/1 






I. 75 


J. 


3 


K. 


2 




3 . 


(C) 


A. 


B. 




C. 


D. 








ASU 


C-3 




7 


64 








ASW 


C-l 




11 


100 








CCC 


C-l 




10 


90 








ELW 


C-l 




11 


100 








I NT 


C-l 




11 


100 








LOG 


C-l 




11 


100 








MIW 


C-4 




4 


36 








MOB 


C-l 




10 


90 








FHR 


C-3 




34 


68 




4 . 


(C) 


70.2/19 












5 . 


(C) 


A. 1. 23 


.0 2 . 




98.6 3. 


30.0 4. 16.0 


5. 167.6 






6. 0 
















B. 1. 121.0 2. 




0 3. 


35.4 4. 29.0 


5. 185.4 






6. 0 












6. 


(C) 


A. ICEX 


90 




A2 . 


PACEX 90 








B. 8-17 


MAR 90 




B2 . 


20-25 MAR 90 








C. 40.2 






C2 . 


20.5 




7. 


(U) 


N/A 












8. 


(C) 


6 DAYS 
















MIDWAY ISLAND 




1-6 MAR 


90 PONY 


EXPRESS 


9. 


(U) 


N/A 












10. 


(C) 


1. SQUADRON SCHEDULED FOR MRCI IN APRIL. 


EXPECT C-2 


IN 


MIW 


FOLLOWING 


MRCI. 











2. 4 CREWS NOT OP READY IN ASU AWAITING REQUAL (A- 39) 
OPPORTUNITY WITH BG FOXTROT ON APR 9. 

3. FLIGHT HOURS LOW DUE TO POST DEPLOYMENT LEAVE. 

THIS PAGE UNCLASSIFIED 
CLASSIFICATION MARKS ARE FOR FORMAT ONLY 

Enel (3) 
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CONFIDENTIAL when filled in 
COMPATWINGS PACINST 3 5 0 0 . 2 7A 

FM : PATRON XXX 

TO: COMPATWINGS PAC MOFFETT FIELD CA//51// 

INFO: COMASWFORPAC PEARL HARBOR HI//ASW3// 

COMPATWING TEN MOFFETT FIELD CA//30// 

COMPATWING TWO BARBERS POINT HI//30// 

COMPATWING ONE KAMI SEYA JA//30// 
CONFIDENTIAL //N03500// 

SUB J : MONTHLY FLIGHT HOUR REPORT FOR MONTH/YEAR (U) 

REF/A/ COMPATWINGSPACINST 3500.27A/1 AUG 91// 

1. IN ACCORDANCE WITH REF A, THE FOLLOWING REPORT IS 
SUBMITTED : 

H 

/ # 

D SOE ONSTA TOTAL CONT 

I. TASKED OPERATIONAL HRS 

A. INDEP ASW 

(1) Type 

B. COORD ASW 

(1) Type 

C. COMBINED ASW 

( 1 ) Type 

D. INDEP INT/SUR 

E. COORD INT/SUR 

F. COMBINED INT/SUR 

G. CCC 

H. COMBINED CCC 

I. ELW 

CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGSPACINST 3500.27A 



PATROL SQUADRON FLIGHT HOUR REPORT CON'T 

H 

/ # 

D SOR ONSTA TOTAL CONT 

J. COORD ELW 

K. COMBINED ELW 

L. ASU 

M. COORD ASU 

N. COMBINED ASU 

O. DEPL. TRANSIT D_ 

P. DET TRANSIT 

Q. PONY EXPRESS 

R. LOGISTICS SUPPORT 

(1) Specify 

S. OTHER 

(1) Specify 

T. TOTAL CONTINGENCY 

U. TOTAL OPERATIONAL 

II. INDEPENDENT TRAINING HOURS 

A. ASW 

(1) CAST 

(2) A- 3 7 

(3) NIB 

(4) OTHER 

(A) Specify 

(5) TOTAL INDEP ASW 



CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGS PACINST 3 5 0 0 . 2 7A 



PATROL SQUADRON FLIGHT HOUR REPORT CON'T 

H 

/ # 

D SOR ONSTA TOTAL 



B. INT/SUR 

(1) A- 30 



(2) OTHER 

(A) Specify 

(3) TOTAL INT/SUR 



C. MIW 

(1) A- 38 



(2) MRCI/WKUP 



( 3 ) OTHER 

(A) Specify 

(4) TOTAL MIW 



D. ELW 

(l) Specify 

E. ASU 

(1) Specify 

F. BOMBEX 

(1) Specify 

G. TOTAL INDEP TRNG 



III. PILOT/CREW TRAINING HOURS 

A. PILOT TRNG 

( 1 ) SYLLABUS 



(2) PPT 



( 3 ) INSTRUMENT 



(4) AIRWAYS 



(5) NATOPS 



CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGSPACINST 3500. 27A 

PATROL SQUADRON FLIGHT HOUR REPORT CON'T 

H 

/ # 

D SOR ONSTA TOTAL 

(6) TOTAL PILOT TRNG 

B. CREW TRNG 

(1) SYLLABUS 

(2) OVR WTR NAV 

(3) NATOPS 

(4) TOTAL CREW TRNG 

C. TOTAL P/C TRNG 

IV. MISCELLANEOUS TRAINING HOURS 

A. MAINT CHECK 

B. MAD COMP 

C. WST TRANS 

D. SCHOOL FLTS 

E . FERRY 

F. OTHER 

(1) Specify 

G. TOTAL MISC 

V. TOTAL TRAINING 

VI. COORDINATED/COMBINED EXERCISE HOURS 

A. COORD ASW 

(1) Specify 

B. COORD INT/SUR 

(1) Specify 

CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGSPACINST 3500. 27A 

PATROL SQUADRON FLIGHT HOUR REPORT CON'T 

H 

/ # 

D SOR ONSTA TOTAL 



C. CCC 

(1) Specify 

D. COORD ASU 
(1) Specify 

E. COORD MIW 
(1) Specify 

F. TOTAL COORD EXERCISE 



G. COMBINED ASW 
(1) Specify 

H. COMBINED INT/SUR 
(1) Specify 

I. COMBINED CCC 
(1) Specify 

J. COMBINED ASU 
(1) Specify 

K. COMBINED MIW 
(1) Specify 

L. TOTAL COMBINED EXER 



M. TOTAL EXERCISE HOURS 



VII. SERVICE HOURS 

A. C/N 



B. AC FT SVCS 
(1) Specify 

C. SAR 



D. CNO PROJECTS 

(1) Proj # 

CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGS PACINST 3 5 0 0 . 2 7A 



PATROL SQUADRON FLIGHT HOUR REPORT CON'T 

H 

/ # 

D SOR ONSTA TOTAL 

E . TAC D&E 

(1) Proj name 

F. RECRUITING 

G. STATIC DISP 

H. ORIENT/DEMO 

I. STAFF SUPPORT 

J. OTHER 

(1) Specify 

K. TOTAL TASKED SERVICES 

VIII. TOTALS 

A. TOTAL MONTHLY HRS H 

B. TOTAL MONTHLY HRS D_ 

C. TOTAL HOURS _H/D 

IX. MONTHLY PILOT ANALYSIS 

A. MONTHLY AVERAGE 1ST TOUR, 1ST PILOT TIME: 

B. NUMBER OF 1ST TOUR PILOTS NOT ACQUIRING 10 HOURS OF 1ST 

PILOT TIME: 

C. NUMBER OF 1ST TOUR PILOTS BEHIND IN PEF : 

D. IP STATUS 

RANK MONTH/ YR DESIG PRD 



CONFIDENTIAL when filled in 
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CONFIDENTIAL when filled in 
COMPATWINGSPACINST 3500.27A 



PATROL SQUADRON FLIGHT HOUR REPORT CON'T 



X. MONTHLY DETACHMENT OPERATIONS 



SITE #ACFT # CREWS tfDAYS OPS 

HRS 



TRNG EXER SVCS 
HRS HRS HRS 



PILOT/CREW 

POSITIONING 



CONFIDENTIAL when filled in 



APPENDIX B. OBJECT DIAGRAMS 



\D 

MANNING 
R-LEVELS 
NIGHTHRS 
FLT HOURS 
DETOPS 



MV 

MV 

MV 

MV 



JD _ _ 

FLTHRS 

MV 

PILOT STATS 

INST PILOTS^ 

, MV 

DETOPS 

MV 



FLTRPT Object 



RDYRPT Object 



SQUADRON 

MONTH 

YEAR 

REPORT 

STATUS 

MV 

ID Object 



ID 



RANK 

MV 

DESIGNATION 

RPD 



ID 

POSITION 

MV 

TOTAL 
GAINS 
LOSSES 
CAT I 
CAT II 
CAT III 



MANNING Object 



ID 

NIGHT HOURS 
% OF TOTAL 



INST PILOTS Object 



NIGHTHRS Object 
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ID 

PMA NAME 

MV 

C-RATING 

CREWS 

PERCENTAGE 



R-LEVELS Object 



JD 

CATEGORY 

AREA 

TYPE 

SPECIFIC TYPE 
MATRIX 

FLT HOURS Object 



ID 

DETTYPE 
DET NAME 
DATE 

TOTAL HRS 

#AIRCRAFT 

#CREWS 

#DAYS 

SITE 

FLTHRS 

MV 

DETOPS Object 



ID 

1ST PILOT TIME 
DEFICIENT PILOTS 
PEF PILOTS 

PILOT STATS Object 



SORTIES 

ONSTATION 

TOTAL 

CONTINGENCY 

FLTHRS 

MATRIX Object 
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APPENDIX C. 



OBJECT DEFINITIONS 



DETOPS OBJECT 

ID; ID Object 
Det Type; Det_Type 
Det Name; Det_Name 
Date; Date 
Total Hrs ; Hrs 
#Acft; Acft 
# Crews; Crews 
#Days ; Days 
Site; Site 

FLTHRS ; FLTHRS Object; MV; SUBSET [Category] 



FLTHRS OBJECT 

ID; ID Object 

Category; Category_Name 

Area ; Area_Name 

Typ e ; Typ e_Name 

Specific Type; Specif ic_Name 

MATRIX; MATRIX Object 



FLTRPT OBJECT 

ID; ID Object 

FLTHRS; FLTHRS Object; MV 

PILOT STATS; PILOT STATS Object; 

INST PILOTS; INST PILOTS Object; MV 

DETOPS; DETOPS Object; MV 



ID OBJECT 

Squadron; Squadron_Number 
Month ; Month 
Year; Year 

Report ; Report_Type ; MV 
Status; Squadron_Status ; MV 
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INST PILOT OBJECT 



ID; ID Object 
Rank ; Rank ; MV 
Desig; Date 
PRD; Date 



MANNING OBJECT 
ID; ID Object 

Position; Position_Name ; MV 
Total; Position_Total 
Gains; Position_Gains 
Losses; Posit ion_Losses 
Cat I; Cat I 
Cat II; Cat II 
Cat III; Cat III 



MATRIX OBJECT 

FLTHRS ; FLTHRS Object 
Sorties; Sorties 
Ons tat ion; Ons ta 
Total ; Hrs 
Contingency; Cont 



NIGHTHRS OBJECT 

ID; ID Object 
Night Hours; Hrs 
% of Total; Percent 



PILOT STATS OBJECT 



ID; ID Object 
1st Pilot Time; 1PT 
Deficient Pilots; DPT 
PEF Pilots; PEF 
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RDYRPT OBJECT 



ID; ID Object; SUBSET [Squadron, Month, Year, Report) 

MANNING; MANNING Object; MV 

R- LEVELS; R- LEVELS Object; MV 

NIGHTHRS; NIGHTHRS Object 

FLTHRS ; FLTHRS Object; MV 

DETOPS; DETOPS Object; MV 



R- LEVELS OBJECT 

ID; ID Object 
PMA; PMA_Name; MV 
C- rating; C- rating 
Crews ; Crews 
Percentage; Percent 
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APPENDIX D. DOMAIN DEFINITIONS 



1PT : 

Numeric 999.9 

Average number of 1st pilot time flight hours for report 
month 

Acf t : 

Numeric 99 

Number of individual aircraft at a detachment site 

Area_Name : 

Text 25 

Indicates second- level categorization of flight hours 

CAT I: 

Numeric 99 

Number of Category I Officers in a squadron during report 
month 

CAT II: 

Numeric 99 

Number of Category II Officers in a squadron during report 
month 

CAT III: 

Numeric 9 

Number of Category III Officers in a squadron during report 
month 

Category _Name : 

Text 25 

Indicates first- level categorization of flight hours 
Cont : 

Numeric 99 

Number of contingency events for a specific category 

C- rating : 

Numeric N 

Rating factor of 1 to 4 assigned to a Primary Mission Area 

Crews : 

Numeric 99 

Specific number of individual crews 



56 



Date : 

Text 6, Mask MMM YY, 

where MMM is the three letter abbreviation for any 
month, YY is the last two digits of any year 
Indicates a month/yr combination 

Days : 

Numeric 999 

Specific number of days at a detachment site 

Det_Name : 

Text 25 

Name of an operation, pers tempo, exercise or contingency 
detachment 

Det_Type; 

Text 25 

Categorizes detachments as one of the following (Exercise, 
Contingency or Perstempo) 



DPT 

Numeric 99 

Numeric measure of the number of pilots in a squadron not 
acquiring 10 hours of first pilot time during the reporting 
month 

Hrs : 

Numeric 9999.9 

Indicates total number of flight hours for a specific 
category for report month 

Month : 

Text 3 

Three letter abbreviation for any month 
Onsta: 

Numeric 999.9 

Number of flight hours onstation associated with one or a 
series of related events 

PEF : 

Numeric 99 

Numeric measure of the number of first tour pilots behind 
in PEF for the reporting month 

Percent : 

Numeric 99 

Percentage ratio of one event or category to another 
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PMA_Name : 

Text 3 

Specifies Primary Mission Area(PMA) for R-Levels object 

Position_gains : 

Numeric 99 

Identifies total number of entity gains for a given 
position 

Position_losses : 

Numeric 99 

Identifies total number of entity losses for a given 
position 

Position_Name : 

Text 7 

Describes position for Manning information (limited to 
Pilots, Nfos or Aircrew) 

Position_total : 

Numeric 99 

Identifies total number of entities for a given position 

Rank: 

Text 4 

Abbreviation for Officer rank in U.S. Naval Service 

Report_Type : 

Text 3 

Identifies type of report where data originated (limited to 
TRR-Training and Readiness Report and FHR-Flight Hour 
Report) 



Site: 

Text 2 5 

Names for detachment locations 

Sorties : 

Numeric 999 

Number of sorties involved with a specific event or series 
of related events 

Specif ic_Name : 

Text 15 

Indicates fourth- level categorization of flight hours 

Squadron_number : 

Numeric 99 

Numeric identifier for a Patrol Squadron 
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Squadron_status : 

Text 8 

Identifies Home or Deployed status of squadron during 
report month 

Type_name : 

Text 10 

Indicates third- level categorization of flight hours 

Year: 

Numeric 2 

Identifies any year by the last two digits 
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APPENDIX E. 



USERS MANUAL 
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I . INTRODUCTION 

ZTRAX is a readiness and flight hour relational database 
management system designed to store squadron training, readiness 
and flight hour data from monthly reports and provide information 
in graphic or tabular form. Specific data and information are 
retrieved using PARADOX query by example (QBE) techniques. A 
working knowledge, i.e completing the Paradox tutorial which 
accompanies the program, of Paradox functions is required to fully 
utilize this application. ZTRAX is run through PARADOX by: 

1. Selecting the Script option of the PARADOX main menu 



View Ask Report Create Modify Image Forms Tools Scripts Play or 
PARADOX Main Menu 



2. Selecting the Play option from the Scripts menu 



Play Begin Query Show Repeat Editor 

Record Save Play Play 

Play a script. 

PARADOX Scripts Menu 



3. Entering "ZTRAX" at the Script prompt. 



Script: ZTRAX 
PARADOX Script s/Play Menu 

Upon program execution the "ZTRAX" main menu will appear at the 
top of the screen. Selection of all menu items in ZTRAX is 
accomplished by using the left/right arrow keys to highlight the 
selection and the enter/return key to select the menu item. The 
escape key may be used at any time to move up one menu level. 
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Readiness Fit Hrs Leave 
ZTRAX Main Menu 

An essential note; after all database operations remember to 
save the updated ZTRAX tables to a backup floppy disk. This will 
insure data integrity in case of system crash. The backup 
procedure is simple. First, because ZTRAX automatically saves the 
new/updated data to the tables on the hard drive you must only save 
that data for a backup copy. After exiting ZTRAX you remain in the 
main Paradox program with the main menu displayed on the screen. 
From here: 

1. Select Tools from the main menu. 



View Ask Report Create Modify Image Forms TOOLS Scripts Exit 
PARADOX Main Menu 



2. Select Copy from the Tools menu. 



Rename QuerrySpeed Exportlmport Copy Delete Info 
TOOLS Menu 



3. Select Table from the Copy menu. 



Table Form Report Script JustFamily Graph 
Cor\^^tab^^anc^^£^am^^^^form£^report^an^^idexes 

Table Menu 
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4. At the Table prompt select the table to copy, in this example 
we will use the FLTHRS table. 



Table: FLTHRS 

Enternameoftabletocoovor<RETURN>toseealist^^^^^^^^ 
PARADOX Tools /Table Menu 

5. After you enter the table name and press return Paradox will 
request a new name to copy the table to. Because this is a backup 
copy we use the same name for the table but specify a new drive and 
directory. In this case, we use the A drive, ZTRAX subdirectory 
and the FLTHRS table name. 



Table: A:\ZTRAX\FLTHRS 
PARADOX Tools /Table Menu 

Backup copies of tables and data are a standard procedure for 
all database operations, regardless of their size or scope. It is 
a safeguard against processor or hard disk failure and is most 
highly recommended for use with ZTRAX. 
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II. ADDING NEW DATA 



There are two distinct ways to enter new data into the tables 
which comprise ZTRAX. The first, and most efficient, is the use of 
the ZTRAX menu structure. The second, used to accomplish any phase 
of database operations, is the manipulation of the PARADOX program. 
This option is not advised for data entry and edit due to the size 
of the tables and the large number of fields contained within them. 

Data entry is accomplished with the keyboard. Incorrectly 
formatted fields, i.e. putting an alphabetic character in a numeric 
field, is met with a beep from the program and a blinking cursor in 
that particular field. The majority of the data entry fields are 
numeric and they follow the format of the source documents, the 
Training and Readiness and Monthly Flight Hour reports. Therefore, 
if a field is numeric on the source document, it is numeric in the 
database . 

A. Readiness Report 

1. Selecting READINESS from the main ZTRAX menu will display the 
following menu: 



ADD EDIT VIEW 

ADD NEW MONTHLY READINESS REPORT DATA 



Readiness Main Menu 



2. Highlighting Add, as shown above, and pressing the 
enter/return key will display a data entry form duplicating a 
readiness message. This form consists of three pages which are 
maneuvered between by using the page or arrow up/down keys. Page 
one of the form is the initial screen and the blinking cursor, to 
the right of SQUADRON, indicates the first point of data entry 
(Fig . 1) . 

3. To enter data just type it as it appears on the readiness 
message into the desired field and press Enter. ZTRAX will advance 
to the next available field automatically. Fields can be skipped 
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by using the arrow keys to select another field. It is recommended 
all fields be entered in CAPITAL LETTERS because PARADOX is case 
sensitive and this will effect later queries. 



MONTHLY READINESS REPORT 



1 . SQUADRON - MONTH YEAR 



MANNING 


TOTAL GAINS 


LOSSES 


CAT I /CATI I /CATI I I 


PILOTS 






/ / 


NFOS 






/ / 


AIRCREW 








R- LEVELS 


C- RATING 


CREWS 


PERCENTAGE 


ASU 


C- 








ASW 


C- 






CCC 


C- 






ELW 




C- 




INT 




C- 




LOG 




C- 




MIW 




C- 




MOB 




C- 




FHR 




C- 


NIGHT HOURS % OF 


TOTAL 





Figure 1 

4. After all fields have been entered press the [F2] key to save 
the new data. The [FI] Help key is the only other operational 
function key available while using ZTRAX. Selecting [FI] will 
retrieve the standard PARADOX Help Screen. 

5. In order to create the proper representation of a readiness 
report for a squadron, it is essential the three key fields; 
Squadron, Month and Year are entered correctly. If any of these 
fields are incorrect, proper queries of data will be impossible. 
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B. Flight Hour Report 

1. All of the procedures and keystrokes used to enter new FLT 
HRS Report data are identical to a READINESS Report. There is, 
however, a more diverse menu structure required to enter all the 
data contained within it. The size of the FLT HRS Report itself 
prohibits PARADOX from allowing data entry on one form. Therefore, 
the menu structure is broken down into five functional categories 
which serve as data entry forms. 

1. Selecting FLT HRS from the main ZTRAX menu will display: 



ADD EDIT DEPLOYED HOME 

ADD NEW MONTHLY FLIGHT HOUR REPORT DATA 

Fit Hrs Main Menu 



2. Highlighting ADD, as shown above, and pressing the enter/ 
return key will display the following menu: 



OPHRS TRNGHRS EXHRS SVCHRS TOTALS 
ADD NEW OPERATIONAL FLIGHT HOUR DATA 

FLT HRS ADD Menu 

3. At this point, data can be entered in any one of the five 
displayed categories. It is recommended you follow the menu 
sequence which is representative of the FLT HRS Report message. 

4. Selection of any highlighted category will display the 
designated report form. The cursor is positioned to the right of 
SQUADRON and data entry is accomplished as previously described. 
Figure 2 on the following page displays the first page of the OPHRS 
entry form. 

5. The difference between the Training and Readiness and Flight 
Hours report header is the addition of a HOME/DEPLOYED field on the 
FLT HRS Report. This key field is adjacent to YEAR and requires 
precise entry, either "H" for HOME or "D" for DEPLOYED. 
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6. Of extreme importance is the consistency with which data is 
entered. For example, in Figure 2 there is a category field for 
Operational Flight Hours, an Area field for ASW, a type field for 
Indep ASW and a specific type field. In this instance, the first 
three fields are automatically entered in the database by entering 
data in the fourth field, specific type. It is essential the 
specific type be entered exactly the same, including upper or lower 
case, for all squadrons in all instances of a report. Any 
deviation will prohibit effective queries because the data will be 
acknowledged by Paradox as being a different. 







OPERATIONAL 


FLIGHT HOURS 






SQUADRON 


MONTH 


YEAR 


HOME /DEPLOYED 


A. 


INDEP ASW 
1 . 

2 . 

3. 

4. 

5. 

TOTAL 
SUM TOTAL 


SORTIES 


ONSTA 


TOTAL CONT 


B. 


COORD ASW 
1 . 

2 . 

3 . 








4. 

5. 

TOTAL 
SUM TOTAL 



Figure 2 



68 



III. EDITING EXISTING DATA 



ZTRAX allows users to edit data existing in the database tables 
by selecting the edit function contained in both the Readiness and 
Flight Hour menus. 

A. Readiness Report 

The selection process for EDIT is similar to ADD. The first 
step is to select Readiness from the main ZTRAX menu. 



ADD EDIT VIEW 

EDIT EXISTING READINESS REPORT DATA 



Readiness Main Menu 



After selecting EDIT from the menu, the following three-step, 
three- screen query will request the squadron, month and year of the 
Readiness Report you want to edit. 

ENTER THE SQUADRON NUMBER: 

ENTER THE MONTH: 

ENTER THE YEAR: 

Answering the three requests will then take you to the edit 
screen. It is exactly the same screen display as the ADD data 
entry form except the data is already there. Any field can be 
edited, including the three key fields squadron, month and year. 
For that reason, extreme care must be exercised when editing any 
report. To complete the edit press the [F2] key to save the new 
data and exit to the main menu. 
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B. Flight Hour Report 

Editing an instance of a Flight Hour report involves similar key 
strokes as those required by the ADD function. The first step is 
to select Fit Hrs from the main menu then EDIT from the Fit Hrs 
main menu. 



ADD EDIT DEPLOYED HOME 

ADD EXISTING MONTHLY FLIGHT HOUR DATA 



Fit Hrs Main Menu 



After selecting EDIT, a menu similar to the ADD menu appears. 
At this point you have the option to choose the specific category 
which requires editing. 



OPHRS TRNGHRS EXHRS SVCHRS TOTALS 
ADD NEW OPERATIONAL FLIGHT HOUR DATA 

FLT HRS ADD Menu 

After one of the above categories is selected, the program will 
request the following four identifying items to determine which 
record to retrieve from the database. 

ENTER THE SQUADRON NUMBER: 

ENTER THE MONTH: 

ENTER THE YEAR: 

ENTER "H" FOR HOME / " D " FOR DEPLOYED 

An EDIT screen is exactly the same as the ADD screen for any 
specific category. Again, all fields are able to be modified so 
use exercise caution. After the EDIT is complete, press the [F2] 
key to save the new data and return to the ZTRAX main menu. 
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IV. QUERY OPERATIONS 

Query functions, both pre-defined and ad hoc, are the heart of 
database operations. The ability to easily retrieve required data 
and information is the goal of any application. ZTRAX provides 
several pre-defined queries which provide information on specific 
categories for single Readiness or Flight Hour report records. By 
exiting ZTRAX and manipulating the Paradox query functions, 
multiple records can be queried to provide the requested 
information. Part A outlines the pre-defined queries. Part B 
outlines and demonstrates some of the Paradox query functions. 

A. Pre-Defined Queries 

ZTRAX offers several pre-defined queries which can readily 
supply information on individual categories for specific instances 
of a Flight Hours or Readiness report. To initiate the query 
function: 

1. From the ZTRAX main menu select either Readiness or Fit Hrs, 
depending upon the origin of the data you want to obtain. 

Readiness Queries 

2. If Readiness is chosen, select VIEW from the main menu. 



ADD EDIT VIEW 

VIEW SPECIFIC MONTHLY READINESS REPORT INFORMATION 
Readiness Main Menu 



3. The Readiness VIEW menu displays six different options. 



MANNING R- LEVELS FLT ACT EXHRS CONT PERSTEMPO 
VIEW MONTHLY SQUADRON MANNING INFORMATION 



Readiness View Menu 
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4. Following the selection of a category to view, ZTRAX will 
request the following information to determine the specific data to 
retrieve . 

ENTER THE SQUADRON NUMBER: 

ENTER THE MONTH: 

ENTER THE YEAR: 

5. Completing the above query after selecting MANNING from the 
Readiness VIEW menu will display the following screen (Figure 3) . 
Similar screens are displayed for all menu selections. It is 
essential to note that due to the level of classification of this 
users manual (UNCLASSIFIED) , none of the fields in any screen 
displays in this manual will contain data. 



SQUADRON MANNING INFORMATION 
SQUADRON NN MONTH MMM YEAR YY 

MANNING TOTAL GAINS LOSSES CATI/CATII/CATIII 

PILOTS / / 

NFOS / / 

AIRCREW 



Figure 3 



6. To exit the query screen, press the [F2] key to return to the 
main ZTRAX menu. 
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Fit Hrs Queries 

1. Selecting Fit Hrs from the main ZTRAX menu will display the 
familiar Fit Hrs main menu. Here, to view any of the predefined 
queries you must first select Deployed or Home from this menu. 
This helps Paradox better define and retrieve the request for 
information. 



ADD EDIT DEPLOYED HOME 
SELECTS DEPLOYED FLIGHT HOUR PATH 



Fit Hrs Main Menu 



2. Choosing Deployed or Home displays essentially the same menu and 
options with the word Deployed substituted for Home in each 
specific case. 

OPHRS TRNGHRS EXHRS SVCHRS TOTALS 

VIEW SPECIFIC DEPLOYED OPERATIONAL FLIGHT HOUR INFORMATION 
FLT HRS DEPLOYED Menu 

3. After category selection is complete, type selections are made 
dependent upon the requirements. For OPHRS, there are six possible 
type selections. 

ASW INT/SUR CCC ELW ASU MISC 

DEPLOYED OPERATIONAL ASW FLIGHT HOUR INFORMATION 
DEPLOYED OPHRS Menu 

4. As displayed above, Deployed Operational ASW Flight Hours 
have been selected. This selection will activate the built-in 
query function designed to identify the desired information in the 
ZTRAX tables. 

ENTER THE SQUADRON NUMBER: 

ENTER THE MONTH: 

ENTER THE YEAR: 
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5. After entering the squadron, month and year of the desired 
report ZTRAX will display the following screen (Figure 4) for 
Deployed Operational ASW Flight Hours. 



DEPLOYED ASW FLIGHT HOURS 

YEAR YY 



TOTAL CONT 

1 . 

2 . 

3. 

4. 

5. 

TOTAL 



COORD ASW 

1 . 

2 . 

3. 

4. 

5. 

TOTAL 



Figure 4 



SQUADRON NN MONTH MMM 

INDEP ASW SORTIES ONSTA 
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B. Ad Hoc Queries 

Ad hoc queries are those that manipulate the actual tables of 
the ZTRAX database to retrieve information. Knowledge of using 
Paradox Query by Example (QBE) techniques is required to perform 
these operations. Training in these procedures is available 
through an on-line tutorial program provided with the complete 
version of Paradox 3.5. Additional help with ad hoc queries can be 
received by depressing the [FI] Help key at any time during a query 
operation . 

To perform a query, you must first tell Paradox which tables the 
data is represented in. ZTRAX is comprised of eleven tables which 
retain all of the data. The following is a list of the tables and 
the data represented within them. 

RDYRPT Table - represents a Training and Readiness report for a 
single squadron, month and year. This table would be selected to 
query an entire report for comparative purposes. 

FLTRPT Table - represents a Flight Hour report for a single 
squadron, month and year. As above, this table would be selected 
to query an entire report for comparative purposes. 

ID Table - represents the identifying information of a Training 
and Readiness or Flight Hour report. This table is contained in 
all other tables to differentiate the data. 

MANNING Table - represents squadron manning levels for officer 
and enlisted aircrew. It is derived from the Training and 
Readiness report. A query of this table might compare pilot 
manning levels between two squadrons for the same month and year. 

INST PILOTS Table - represents data on number of instructor 
pilots a squadron has, their rank, qualification and rotation 
dates. A sample query for this table might ask for all the pilots 
with rotation dates after a specific date. This table is derived 
from the monthly Flight our report. 

NIGHTHRS Table - represents the number of night flight hours a 
squadron completed for a month and year and the percentage of their 
total flight hours were night hours. This table is derived from 
the Training and Readiness report. A sample query might ask 
for the average number of night flight hours for all the squadron 
over a period of time. 
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R- LEVELS Table - is derived from the Training and Readiness 
report. It represents tactical aircrew readiness levels (C- ratings) 
in Primary Mission Areas (PMA) and the number and percentage of 
crews rated C-l for a squadron during a report month. A sample 
query might ask for the number of C-l rated aircrews a squadron has 
maintained in a particular PMA over the last year. 

DETOPS Table - represents various data related to detachment 
operations. This table is familiar to both source documents with 
each using a portion of the fields in the table. Sample queries 
can display multiple squadron/aircraft/site detachment information. 

PILOT STATS Table - represents specific facts able first tour 
junior officer pilot statistics. It is familiar to the Flight Hour 
report and can provide comparative analysis of squadrons and their 
pilot training programs, if queried. 

FLTHRS and MATRIX Tables - these table represent the majority 
of the monthly Flight Hour report. FLTHRS breaks down individual 
sorties or groups of sorties into categories, areas, types and 
specific types. Matrix then assigns the number of sorties, 
onstation hours, total hours and contingency count for each entity 
in the FLTHRS table. To query any information about flight hours 
the first step is to determine which category you need. Because 
ZTRAX automatically enters several of these fields during the 
initial data entry process the names used for category, area, type 
and specific type must be precisely the same when queried. The 
following pages contain the names ZTRAX uses for these fields. The 
only field entered by the user during data entry is specific type. 
This must be entered consistently every time or the resulting 
queries will be incorrect. 



The first example is the body of a Training and Readiness 
report. This is where all the raw data is contained. The 
identifying numbers and letters correspond exactly to those on an 
actual report. Beside each number is a brief explanation of which 
table the data is located in and the recommended field and record 
names to use for queries. Familiarity with the Paradox query by 
example techniques are required to complete an query operation. 
The first section of the Training and Readiness report below will 
briefly describe the necessary procedures to use QBE. Two complete 
query screen examples will follow the Flight Hour report fields 
example . 
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1. MONTHLY TRAINING and READINESS REPORT 

1. This is the header of the report. The ID table represents 
this data and will be required for all queries of this report. To 
query this section of the report place check marks on the Paradox 
query screen under SQUADRON, MONTH and YEAR. Below the check marks 
in each field place an example of the data you want to retrieve, 
for example; if you want information about Patrol Squadron Nineteen 
for the month of January, 1990 you would place a 19 underneath the 
check mark for SQUADRON, a JAN underneath the check mark for MONTH 
and a 90 underneath the check mark for YEAR. 

2. This section concerns squadron manning. Data is found in 
the MANNING table. To query, under the position field place either 
PILOT, NFO or AIRCREW and check either GAINS, LOSSES, TOTAL, CAT I, 
CAT II or CAT III. 

3. This section concerns squadron readiness levels by PMA. 
Data is found in the R-LEVELS table. To query, under the PMA field 
place any one of the nine PMA's then place check marks under C- 
RATING, CREWS and PERCENTAGE, as required for your query. 

4. This sections contains night flight hour data and is found 
in the NIGHTHRS table. To query, place checks under both NIGHT 
HOURS and % OF TOTAL. 

5. This section contain data about the breakdown of flight hours 
for the report period. The data is found in two tables, the 
FLTHOURS table and MATRIX table. To query, first retrieve the 
FLTHOURS table. Place checks under CATEGORY and use the following 
as examples of the query, depending on your requirements, TRNGHRS 
for Training Hours, OPHRS for Operational Hours, SVCHRS for Service 
Hours, EXHRS for Exercise Hours, CONHRS for Contingency Hours and 
TOTALHRS for Total Flight Hours. Then select the MATRIX table and 
place a check under TOTAL for total hours. 

6. 7, 8. Data for these three area are all obtained from the 
same table, DETOPS. To query these, place check marks under the 
required fields and then place examples, as required by your query. 
The following fields correspond to the various items of items 6,7, 
and 8. DET TYPE represents an Exercise or Contingency (items 6 and 
7) . DET NAME is the detachment name and is used for all three 
items. DATE is the date of detachment and used by all three items. 
TOTAL HRS is only used by item 6, Exercise, and represents the 
total flight hours involved with the detachment. #DAYS is only 
used by item 8, Pers tempo, to indicate length of detachment. 
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2. MONTHLY FLIGHT HOUR REPORT 



The monthly Flight Hour report differs somewhat from the 
Training and Readiness report because the majority of the data is 
stored in two tables, FLTHRS and MATRIX. This results from the 
fact that the majority of data in this report involves flight 
hours. It is essential to indicate precisely the data you want to 
obtain in the query. Correct and consistent usage of field names 
during the data entry stage will result in the ability to 
effectively query this data. The following provides, in a sequence 
relative to the Flight Hour report source document, the field names 
used by ZTRAX and the recommended record entries for various flight 
hour categories, areas, types and specific types. 

I. TASKED OPERATIONAL HOURS 

To query all the information in this category, on the FLTHRS 
table query form check the CATEGORY field and place the example 
OPHRS below the check mark. 

A. Independent ASW is queried by placing a check under AREA and 
placing ASW below it, then checking TYPE and placing INDEP below 
the check. Because there are many types of Independent ASW, the 
SPECIFIC TYPE field will separate them. Place a check under 
SPECIFIC TYPE and place the name of the SPECIFIC TYPE you want to 
query. Of great importance here is the consistent use of the same 
manes for SPECIFIC TYPES over the course of using this program. It 
is recommended they be documented in the space provided at the end 
of this chapter of the manual . 

After completing the FLTHRS portion of the query retrieve the 
MATRIX table. Here you can place check marks in any of the desired 
fields you require. There are no examples required for the MATRIX 
table . 

B. Coordinated ASW works exactly like the above example. Place 
ASW under the AREA check mark and COORD under the TYPE field check 
mark. SPECIFIC TYPE is as previously outlined. After this is 
completed, again go to the MATRIX table to select your query 
choices . 

C. Combined ASW uses COMB in the TYPE field. The rest remains 
as previously described. 

D. Independent INT/SUR uses INT/SUR in the AREA field and INDEP 
in the TYPE field. No SPECIFIC TYPE is available. 

E. Coordinated INT/SUR uses INT/SUR in the AREA field and COORD 
in the TYPE field. No SPECIFIC TYPE is available. 

F. Combined INT/SUR uses INT/SUR for the AREA field and COMB in 
the TYPE field. No SPECIFIC TYPE is available. 
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G. CCC is used in the AREA field. No TYPE or SPECIFIC TYPE are 
required. 

H. Combined CCC uses CCC in the AREA field and COMB in the TYPE 
field. No SPECIFIC TYPE is available. 

I. ELW is used in the AREA field. No TYPE or SPECIFIC TYPE are 
required. 

J. Coordinated ELW uses ELW in the AREA field and COORD in the 
TYPE field. SPECIFIC TYPE is not available. 

K. Combined ELW uses ELW in the AREA field and COMB in the TYPE 
field. SPECIFIC TYPE is not available. 

L. ASU is used for the AREA field. TYPE and SPECIFIC TYPE are 
not available. 

M. Coordinated ASU uses ASU for the AREA field and COORD in the 
TYPE field. SPECIFIC TYPE is not available. 

N. Combined ASU uses ASU for the AREA field and COMB for the 
TYPE field. SPECIFIC TYPE is not available. 

O. Deployment Transit uses DEPXSIT for the AREA field. No other 
fields are available. 

P. Detachment Transit uses DETXSIT for the AREA field. No other 
fields are available. 

Q. Pony Express is used in the AREA field. No other fields are 
used. 

R. Log Support is used in the AREA field and the names of 
various Log Support events are contained in SPECIFIC TYPE. There 
is no entry for TYPE. 

S. Other is used in the AREA field and the various Other names 
are contained in SPECIFIC TYPE. There is no entry for TYPE. 

T. Total Contingency uses TOTAL CONT in the AREA field. There 
is no use of TYPE or SPECIFIC TYPE for this area. 

U. Total Operational uses TOTAL OP in the AREA field. There is 
no use of TYPE or SPECIFIC TYPE for this area. 
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II. INDEPENDENT TRAINING HOURS 



To query the data in this category use INDEP TRNGHRS for the 
CATEGORY in the FLTHRS table. As above, after filling the 
appropriate blocks in FLTHRS, retrieve MATRIX and checks the 
necessary blocks as required. 

A. ASW is the AREA field and is used in the following 1-5. 

1. CAST is the TYPE field. 

2. A- 37 is the TYPE field. 

3. NIB is the TYPE field. 

4. OTHER is the TYPE field. Use SPECIFIC TYPE to specify 
the event you require. 

5. TOTAL ASW is the TYPE field. 



B. INT/SUR is the AREA field for the following 1-3. 

1. A- 30 is the TYPE field. 

2. OTHER is the TYPE field. Use SPECIFIC TYPE for the event 
you require. 

3. TOTAL INT/SUR is the TYPE field. 

C. MIW is the AREA field and used in the following 1-4. 

1. A- 38 is the TYPE field. 

2. MRCI/WKUP is the TYPE field. 

3. OTHER is the TYPE field. Use SPECIFIC TYPE for the event 
you require. 

4. TOTAL MIW is the TYPE field. 

D. ELW is the AREA field, SPECIFIC TYPE lists specific events. 

E. ASU is the AREA field, SPECIFIC TYPE lists specific events. 

F. BOMBEX is the AREA field, SPECIFIC TYPE lists specific 
events . 

G. TOTAL TRAINING is the AREA field. No TYPE or SPECIFIC TYPE 
is required. 

III. PILOT/CREW TRAINING HOURS 

To query data in this category use PCTRNG for CATEGORY in the 
FLTHRS table. After filling in the appropriate fields, use the 
MATRIX table to specify the information you need. 

A. PILOT TRAINING is the AREA field. Use it for the following 
1-6 items. 

1. SYLLABUS is the TYPE field. 

2. PPT is the TYPE field. 

3. INSTRUMENT is the TYPE field. 

4. AIRWAYS is the TYPE field. 
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5. NATOPS is the TYPE field. 

6. TOTAL is the TYPE field. 

B. CREW TRAINING is the AREA field. Use it for the following 1- 
4 items. 

1. SYLLABUS is the TYPE field. 

2. OVRWTRNAV is the TYPE field. 

3. NATOPS is the TYPE field. 

4. TOTAL is the TYPE field. 

C. TOTAL is the AREA field. This retrieves total figures for 
Pilot Crew training. 



IV. MISCELLANEOUS TRAINING HOURS 

To query data form this category use MISCTRNG in the CATEGORY 
field of FLTHRS. The use of the MATRIX table is the same as 
previously described. 

A. MAINT CHECK is the AREA field. 

B. MAD COMP is the AREA field. 

C. WST TRANSIT is the AREA field. 

D. SCHOOL FLTS is the AREA field. 

E. FERRY is the AREA field. 

F. OTHER is the AREA field. SPECIFIC TYPE is used to specify 
each named event . 

G. TOTAL is the AREA field. 



V. TOTAL TRAINING is the CATEGORY. There are no AREA or TYPE 
fields relative to this category. 



VI. COORD /COMBINED EXERCISES 

Exercise is the CATEGORY name for this field. There are two 
TYPE fields associated with this section, COORD for Coordinated and 
COMB for Combined. 

A. COORD is the TYPE field, ASW is the AREA field. SPECIFIC 
TYPE lists the various events for the category. It is essential 
all SPECIFIC TYPE names coincide with the terms used during data 
entry. 

B. COORD is the TYPE field, INT/SUR is the AREA field. SPECIFIC 
TYPE lists the various events in this area. 

C. COORD is the TYPE field, CCC is the AREA field. SPECIFIC 
TYPE lists the various events in this area. 

D. COORD is the TYPE field, ASU is the AREA field. SPECIFIC 
TYPE lists the various events in the area. 
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E. COORD is the TYPE field, MIW is the AREA field. SPECIFIC 
TYPE lists the various events in the area. 

F. COORD is the TYPE field, TOTAL is the AREA field. 

G. COMB is the TYPE field, ASW is the AREA field. SPECIFIC TYPE 
lists the various events in the area. 

H. COMB is the TYPE field, INT/SUR is the AREA field. SPECIFIC 
TYPE lists the various events in the area. 

I. COMB is the TYPE field, CCC is the AREA field. SPECIFIC TYPE 
lists the various events in the area. 

J. COMB is the TYPE field, ASU is the AREA field. SPECIFIC TYPE 
lists the various events in the area. 

K. COMB is the TYPE field, MIW is the AREA field. SPECIFIC TYPE 
lists various events in the area. 

L. COMB is the TYPE field, TOTAL is the AREA field. 

M. TOTAL is the TYPE field. 



VII. SERVICES 

To query this category use SVCS in the field for CATEGORY. 
After all other query information for FLTHRS is complete, then USE 
the MATRIX table to identify the data you need. 

A. C/N is the AREA field. 

B. ACFT SVCS is the AREA field. 

C. SAR is the AREA field. 

D. CNO PROJECTS is the AREA field, SPECIFIC TYPE lists the 
various projects in this area. 

E. TAC D&E is the AREA field, SPECIFIC TYPE lists the various 
Tac D&E projects in this area. 

F. RECRUITING is the AREA field. 

G. STATIC DISPLAY is the AREA field. 

H. ORIENT/DEMO is the AREA field. 

I. STAFF SUPPORT is the AREA field. 
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J. OTHER is the AREA field, SPECIFIC TYPE identifies the 
various entries for this area. 

K. TOTAL is the AREA field. 

VIII. TOTAL FLIGHT HOURS 

TOTALS is the CATEGORY field for this section of the report. 
The data is found in the FLTHRS and MATRIX tables. 

A. HOME is the AREA field. 

B. DEPLOYED is the AREA field. 

C. TOTAL is the AREA field. 



IX. MONTHLY PILOT ANALYSIS 
To query this section use the PILOT STATS table. 

A. 1ST PILOT TIME. Place a check under this field to query 1st 
Pilot Time. 

B. DEFICIENT PILOTS. Place a check under this field to query 
1st Tour Pilots < 10 Hours 1st Pilot Time. 

C. PEF. Place a check mark under this field to query 1st Tour 
PEF Pilots. 

D. IP STATUS uses the INST PILOTS table to maintain its data. 
To query this data: 

1. Place a check mark under RANK and enter the rank of the 
instructor pilots you want to search. 

2. Place a check mark under DESIGNATION. 

3. Place a check mark under PRD. 



X. MONTHLY DETACHMENT OPERATIONS 

To query this section use the DETOPS table (items 1-4,9) and the 
FLTHRS and MATRIX tables (items 5-8). As explained before, place 
check marks below the fields you desire then place examples 
underneath the checks. Imperative here is that data entry names 
exactly coincide with query example names. 

1. SITE is an alphabetic name for the detachment site. 

2. #A/C is a numeric entry for the number of aircraft present at 
the site. 

3. #CREWS is a numeric entry for the number of aircrew present 
at the detachment site. 

4 . #DAYS is a numeric entry for the number of days a detachment 
has been operational. 
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5. OPHRS is a numeric entry of flight hours. Use OPHRS for the 
CATEGORY field of FLTHRS , TOTAL from the MATRIX table. 

6. TRNGHRS in the CATEGORY field, TOTAL from the MATRIX table. 

7. EXHRS in the CATEGORY field, TOTAL from the MATRIX table. 

8. SVCHRS in the CATEGORY field, TOTAL from the MATRIX table. 

9. P/C POSIT is the TOTALHRS field in DETOPS. This gives the 

transit time to the detachment. 
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The use and manipulation of Paradox query by example techniques 
are profiled extensively in the Paradox Users Manual that 
accompanies the program documentation. The following examples are 
based directly from that manual and reflect the operation of the 
Paradox program, not ZTRAX. Therefore, familiarity with Paradox 
query operations is essential prior to attempting any queries with 
ZTRAX. 

The query charts on the previous pages specified the various 
tables to query for information in a particular case. It also 
provided the field names ZTRAX uses in very specific instances. 
Now, two examples of ZTRAX ad hoc queries will be shown. The first 
is a single query, the second is a multiple query. Both will 
follow the same format, first will be a description of the 
requested information, next the tables and required fields for the 
query will be identified using the query charts, and last, query 
screen displays, with explanations, will be provided. 

3 . SINGLE QUERY 

This first example will be a relatively simple query to 
reinforce the Paradox query by example techniques and allow you to 
get a feel for finding field names in the query charts. 

Problem: You want to find out the total number of sorties for 
tasked operational flight hours for independent ASW during the home 
cycle for Patrol Squadron 1, for the month of JAN 1991. 

STEP 1 - From the PARADOX main menu select ASK. 



View ASK Report Create Modify Image Forms Tools Scripts Help 
PARADOX Main Menu 



STEP 2 - From the Ask menu, enter the table name which you wish 
to query, in this case FLTHRS. 
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Table : FLTHRS Main 

Ente^nam^o^tabl^t^asl^abou^^o^nres^ente^t^se^^^^^^ 

ASK Menu 



*[F6] to include a field in the ANSWER; [F5] to give an example 



=FLTHRS=====SQUADRON=======MONTH=======YEAR======STATUS 

= * 1 = * JAN = * 91 = * HOME 



FLTHRS ===CATEGORY===AREA======TYPE===SPECIFIC TYPE===SORTIES 

= * OPHRS = * ASW = * INDEP= (NO ENTRY REQD) = * 



Paradox Query Form 



STEP 3 - The display above is the Paradox query form. It is 
reproduction of the FLTHRS table in tabular format. An asterisk 
has been substituted for the check mark normally found in Paradox. 
You can run the entire length of the table by using the right arrow 
key. The first step in this query is to identify the key fields 
squadron, month, year and status. This has been done as shown in 
the top portion of the form. Next, identify the CATEGORY, AREA and 
TYPE and place the examples as shown. Notice SPECIFIC TYPE is not 
required by this query. After all entries are complete press the 
[F2] to activate the query. Paradox will then display the output 
screen shown below. At this point you also have the option of 
printing the screen display. Those procedures are outlined in the 
Paradox manual . 
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ANSWER SQUADRON MONTH YEAR STATUS CATEGORY AREA TYPE SORTIES 
1 1 JAN = 91 = HOME = OPHRS = ASW =INDEP= 20 



4 . MULTIPLE QUERY 

This example will show a typical multiple query ZTRAX might be 
asked to provide. The format will be the same as Example 1. 

Problem: You want to compare Pilot manning statistics for two 
different squadrons for the month/year JAN 91. 

Step 1 - From the Paradox main menu select the ASK option. 

Step 2 - From the ASK main menu enter the table to be used for 
the query. In this case the data comes from the monthly Training 
and Readiness report. You determine the MANNING table holds the 
information you desire so enter Manning at the prompt. 



Table: MANNING Main 
ASK Menu 

Step 3 - Knowing the query function requires the key fields to 
be entered, do that first for both squadrons. Next, the data about 
Pilot manning is in the POSITION field, put a check under POSITION 
and the example PILOT beside it. All pilot statistics are desired 
so place check marks in GAINS, LOSSES, TOTAL, CAT I, CAT II and CAT 
III. Do this twice, once for each squadron. Press [F2] when the 
form is completed and receive the answer. 
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*[F6] to include a field in the ANSWER; [F5] to give an example 



=MANNING= = =SQUADRON= ===== =MONTH= ===== =YEAR== ==== STATUS 

= * 17 = * JAN = * 91 = * HOME 

= * 1 = * JAN = * 91 = * HOME 



=POSITION===TOTAL===GAINS===LOSSES===CATI===CATII===CATIII== 

♦pilot = * = * = * = *= *= * 

★ =★ = * = * = *= *= * 



Paradox Query Form 



The answer to the above query looks like this. After you have 
completed this query press the [F8] key to clear the screen and 
return to the main Paradox menu. 



ANSWER SQUADRON MONTH YEAR STATUS POSITION TOTAL GAINS LOSSES 



1 = 17 JAN = 91 = HOME = PILOT = 33 = 3 = 5 

2 1 JAN = 91 = HOME = PILOT = 32 = 4 = 3 



Notice the entire query does not fit on the page. Using the 
left/right arrow keys you can view the remainder of the query. 
This is a screen limitation imposed by Paradox. 

Two sample queries have provided some insight into effectively 
utilizing the Paradox ASK function. Further reference can be 
obtained in the Paradox Users Manual. 
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V. GRAPHICAL OUTPUTS 

Paradox allows a users to display any data from Paradox and 
ZTRAX tables on a variety of business style graphs, such as pie, 
bar, area, line and mixed charts. Procedures for defining and 
using graphs are found in the Paradox users manual. This chapter 
will provide a brief overview of integrating Lotus 1-2-3, Quattro 
Pro and dBase II, III or IV and Ascii formatted files into or from 
a Paradox database table. 

The Tools selection found in the Paradox main menu contains an 
Export/Import option. This allows you to transfer data to and from 
other software systems. After selecting the Import/Export option 
you have the two following choices: 

EXPORT IMPORT 

Selecting either of these options displays the following submenu: 

QUATTRO PRO 1-2-3 SYMPHONY dBASE PFS REFLEX 

VISICALC ASCII 

An important point here is that Paradox always converts the data to 
Paradox format through copying the entire file, that way the data 
is left unchanged, an allowing you to rename the file for Paradox's 
purposes . 

The selection Quattro Pro allows you to import data from a 
spreadsheet into a Paradox table, or export a Paradox table into a 
Quattro spreadsheet. When importing spreadsheet data into Paradox, 
remember Paradox stores information in even row and columns whereas 
a spreadsheet lets you arrange the text, numbers and formulas in 
any manner you desire. 

Selecting 1-2-3 from the above submenu and you receive these 
options : 

1) 1-2-3-RELEASE 1A 2) 1-2 -3 -RELEASE 2 

Here you select the appropriate option for the version of 1-2- 
3 you will use. Paradox allows you to import and export data as 
described above. Be sure to specify the correct directories when 
copying to and from a hard drive to avoid confusing your files. As 
before, Paradox cannot import randomly place data in a spreadsheet. 
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It must import by columns and rows, where the top row contains 
field names for the database table. If your spreadsheet contains 
labels or formulas outside of a column/row orientation, you should 
use the File Xtract option discussed in the Paradox users manual . 

Transferring to and from dBase applications is a simple process 
because both programs store data in rows and columns (records and 
fields) . Selecting dBase from the options menu will display the 
following : 

dBASE II dBASE III 

Paradox will copy the data to the file name you have provided 
with a DBF extension. Importing dBase files are just a simple, 
however dBase logical fields will be converted to Paradox 
alphanumeric fields with a length of one character and memo fields 
will be trimmed to a maximum of 255 characters and stored as 
alphanumeric data. 

Paradox also allows the Import/Export of ascii coded files. 
Selecting the Ascii option of the Import/Export menu, then 
selecting Export displays the following: 

DELIMITED TEXT 

Selecting the Import option of the Ascii menu displays the 
following : 

DELIMITED APPEND/DELIMITED TEXT 

Delimited import/export of text is used for software 
applications that can only import/export ascii formatted files. To 
use this option you would first create a delimited export file, 
then import it into the other software application you want to use. 
The Paradox users manual specifically outlines these procedures. 
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VI. PROGRAM MAINTENANCE 

Program maintenance of ZTRAX was designed to be as easy as 
possible. To change any tables, scripts or input/output screen 
displays you will use Paradox Personal Programmer (PPROG) . 

A. Perfective Maintenance 

To start PPROG; from the DOS prompt change directories to ZTRAX. 
This will place all the ZTRAX tables in the current directory. 

C : \ ZTRAX 

Then type a path statement, as follows: 

C:\ZTRAX > PATH=C: \PDOX35 ; C: \PDOX35\PPROG; 

This will load PPROG in RAM along with ZTRAX. Start PPROG by 
typing "PPROG" at the DOS prompt. 

The initial PPROG screen will allow the follow options: 

CREATE MODIFY SUMMARIZE REVIEW PLAY TOOLS QUIT 
Select the Modify option and type ZTRAX at the prompt. PPROG will 
load the ZTRAX menu structure and display the ZTRAX main menu on 
the screen with several edit options. Prior to initializing PPROG 
you should have determined exactly what you want to modify in 
ZTRAX. The entire program is able to be modified through PPROG so 
exercise caution when doing so. 

Guidance on using PPROG is contained in the Paradox users manual 
however it is not the only way to modify ZTRAX. For instance, to 
add a new field to a ZTRAX table you must retrieve the table from 
the Paradox main menu and modify it but then you will have to 
modify the input and edit screens for the new field , this is more 
difficult to accomplish in Paradox than in PPROG. It is 
recommended PPROG be used for all program modifications except 
modifying the tables. Below, for reference purposes, is a sample 
ZTRAX program modification. 

Problem: Adding a new numerical field called AVERAGE in the 
MANNING table. This field will be a required entry on the data 
input form and represents the average number of aircrew personnel 
in a specific position for the previous twelve months. 
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STEP 1 - Adding the new field to the MANNING table is simple. 
From the Paradox main menu you retrieve the MANNING table, select 
edit, and add the new field where it is required. In this case, we 
would add the new field, AVERAGE, immediately before the TOTALS 
field. Because this new field is numeric, simply enter an N in the 
field type column, shown below. Press the [F2] key when complete. 



Modify MANNING Table 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
STRUCT=== ===FIELD NAME=========== FIELD TYPE======== 

4 = POSITION = A7 

5 = AVERAGE = N 

6 = TOTAL = N 

7 = GAINS = N 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



MANNING Table 



STEP 2 - Now that the table has been modified, start the PPROG 
application as shown above. Next, select modify and type ZTRAX at 
the prompt. You will be presented with the following PPROG Modify 
edit screen: 
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Tables MenuAction NotDefined SplashScreen DO- IT Cancel 
Modify a menu selection of an action associated with a menu 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

===============The Paradox Personal Programmer=============== 

Modifying ZTRAX Application 

TABLES allows you to add or remove one or more tables 
MENUACTION allows you to modify the selection/actions in menu 
NOTDEFINED takes you to the first undefined menu selection 
SPLASHSCREEN allows you to modify an application's first screen 
DO- IT! saves all changes you have made to the application 
PPROG Modify Menu 



STEP 3 - Select MENUACTION from the screen above, this will 

display the screen shown below. 



READINESS FLTHRS Leave 
MONTHLY READINESS REPORT 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

====== =========The Paradox Personal Programmer== ============= 

Modifying ZTRAX Application 

Pick the menu selection you want to modify. 



Use the <- -> keys to move around the display 

Press | (ENTER) to move down a menu level, [ESC] to move up 

When the menu selection you want to modify is highlighted, 
press [F10] to display the action menu, then select the type 
of modification you want to make. 



PPROG MenuAction Menu 



STEP 4 - The next step is to press the [F10] key to retrieve the 
action menu as shown below. 
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Menu Action DO- IT! Cancel 
Modify the current menu action 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X READINESS FLTHRS Leave X 

X MONTHLY READINESS REPORT X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

=============== Th e Paradox Personal Programmer=============== 

Modifying ZTRAX Application 
Current menu level : MAIN 

Specify whether you want to modify a menu or an action. 



Menu allows you to modify the current menu level. You can add 
new selections, edit existing selections, or delete selections. 
If you delete a menu selection, all actions or lower- level 
menus attached to that selection will be deleted as well. 

ACTION allows you to modify the action associated with the 
current menu selection. 

DO-IT! save the modifications you have specified to this 
point . 

PPROG MenuAction Menu 



STEP 5 - Next, select ACTION from the previous menu and the 
following menu appears. From this next menu you will select Revise 
with the cursor highlighting ADD. 

STEP 6 - Selecting REVISE will place another screen display from 
which you will have two options: keep or modify the existing table 
or view. By selecting modify you can select the MANNING table and 
make the new field entry, as we have already done in Paradox, or 
select keep the current table and then move to the next menu 
selection screen. 

STEP 7 - The next screen involves the existing input form for 
the ADD option of the menu. The following page is a reproduction, 
as all of these screens in this section are, of the next PPROG 
screen. In this screen you select modify because you need to add 
the new field you entered in the table. 
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— ll 

Define Revise Borrow MoveDown 
Modify the existing definition 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X ADD EDIT VIEW X 

X ADD NEW MONTHLY READINESS REPORT DATA X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
===============The Paradox Personal Programmer=============== 

Modifying ZTRAX Application 

Modifying ADD selection in MAIN/READINESS menu. 

Specify the kind of modification to make. 



DEFINE allows you to redefine the current menu selection if it 
is already defined, or to define it for the first time if it 
is currently NotDefined. 

REVISE lets you modify the components of the current selections 
definition. 

BORROW lets you copy the definition of an already-defined 
selection to the current selection 

MOVEDOWN lets you push the current selection down to a lower 
menu level and create a new menu selection in its place on the 
current level. 

PPROG MenuAction Menu 



Keep Modify FormView TableView FormToggle 
Modify the existing form 

======= ========The Paradox Personal Programmer== ======= ====== 

Modifying ZTRAX Application 

Modifying ADD selection in MAIN/ READINESS menu. 

Indicate whether you want to keep or modify the existing form 



KEEP retains the existing form specification. 

MODIFY changes the existing form. 

FORMVIEW displays the information in form view. 

TABLEVIEW displays the information in table view. 

FORMTOGGLE lets the user switch between form and table view. 



PPROG MenuAction Menu 



STEP 8 - This last menu screen lets you modify the existing form 
based on the modification requirements. In this case you would 
select Field from the menu across the top of the form and insert 
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the new field where you desire. After this action is complete 
select DO-IT! from the menu bar or press the [F2] key. 

Field Area Border Page Style Multi Help DO-IT! Cancel Form 

Place, erase, reformat, recalculate, or wrap a field 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1. SQUADRON MONTH YEAR 

2. MANNING AVERAGE TOTAL GAINS LOSSES CATI/CATII/CATIII 

PILOTS / / 

NFOS / / 

AIRCREW 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Modify Form View 

After completing the screen modification you then repeat the 
same procedure for the EDIT menu and the VIEW/MANNING information. 
They are the same steps just different forms. When all of the 
forms have been modified select DO-IT! form the current menu or 
press the [F2] key. PPROG will save the changes you made and 

regenerate the scripts using the modified table and screens. For 
any additional help with PPROG consult the Paradox users manual. 

B. Data Archiving 

The difference between an archive and backup copy is the archive 
is a historical record of all of the data entered into, and 
possibly deleted from, the database. A backup copy is an exact 
reproduction of the records contained in the database at the 
present time. Archiving is an essential procedure of database 
operations. It is useful for providing several iterations of 
historical records that have been deleted from the existing 
database and to provide a secondary backup copy of current 
application records. 

Data archiving is accomplished in a similar manner as data 
backup, presented in section one of this manual. Archiving should 
be done simultaneously, during data backup, to prevent deleting any 
data without a floppy disk copy and to provide more available space 
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on the hard disk. Given the lack of available hard disk space on 
the current Z-284 system's, archiving is a necessity in the 
department. It is recommended only two years of current Training, 
Readiness and Flight Hour 

data be kept on the system. This will provide enough data to 
encompass an entire training/deployment cycle for a squadron (18 
months) and leave six months for contingency purposes. This two 
years of data will require approximately 650Kb of memory to store. 
If current hard disk limitations remain in effect, this will still 
leave about 300Kb for other documents and files. It is strongly 
recommended that the remaining applications in use be purged of 
their outdated data to free up more memory. 

Data archiving makes use of the Paradox copy command, however 
there are some differences between archiving and making backup 
copies. To begin, archiving is a dynamic record of all data ever 
stored in the ZTRAX database. Backup copies are just a copy of the 
current records in use on ZTRAX. The difference in the copy 
commands is subtle, but important. To make archive copies you 
should first make backup copies as described in section one. Next, 
using the same copy command, copy INDIVIDUAL records for the newest 
files in the database (they should be ones you just entered into 
ZTRAX) onto the archive disk. If you copy the entire table you 
will delete the existing table on the archive disk. This will 
destroy all historical data on the disk and replace it with another 
table. Every month you should archive, then delete, 18 records 
from the database. That is one Training and Readiness Report and 
one Flight Hour Report for each squadron. 
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To archive records follow these procedures: 

1. Select Tools from the main menu. 



View Ask Report Create Modify Image Forms TOOLS Scripts Rename, 
PARADOX Main Menu 



2. Select More from the Tools menu. 



Rename QuerrySpeed Exportlmport Copy Delete More 
TOOLS Menu 



3. Select Add from the Tools/More menu. 



Add MultiAdd FormAdd Subtract Empty Protect ToDos 
j\ddrecordsinonetabletothoseinanothe3^^_^_____ 

Add Menu 



4. At the Table prompt select the table to copy, in this example 
we will use the FLTHRS table. 



Table: FLTHRS 
PARADOX Tools /Table Menu 

5. After you enter the table name and press return Paradox will 
request a new name to copy the table to. Because this is an 
archive copy we use the same name for the table but specify a new 
drive and directory. In this case, we use the A drive, ZTRAX 
subdirectory and the FLTHRS table name. 
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Table: A:\ZTRAX\FLTHRS 
PARADOX Tools /Table Menu 

6. Next, Paradox will display the following screen. Select 
Update with the cursor and press the return key. Paradox will 
automatically update the records in the destination file. It is 
essential archiving be done AFTER new data entries for the month 
are completed. This will ensure the archive copy is correct and 
complete . 



NewEntries Update 
Add Menu 

Archiving is another essential procedure which will insure 
the integrity of ZTRAX. It makes use of another simple Paradox 
utility, Tools/Add/Update. 
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C. FL IMPORT 

FLIMPORT is a Paradox utility designed to allow direct data 
transfer from floppy disks into Paradox database tables. Either 
individual files or an entire disk can be updated by using a batch 
processing option within FLIMPORT. The activation of this utility 
will eliminate all the manual data entry currently required to 
update the ZTRAX database. Also, the time required for edits of 
data entry errors will be reduced to a nominal amount. 

To effectively use this utility the files on the floppy disk 
must be in a fixed- length ASCII format. This capability is avail- 
able from some Navy communications centers however, it is not 
currently a standardized practice. Once the floppy disks contain- 
ing the monthly reports are received from the communications 
center, they can be readily transferred to the ZTRAX database 
tables through a specification file. To use this specification 
file you must first identify all of the fields contained in the 
monthly messages. These are the fields names used in the ZTRAX 
tables. You then assign a field length for each field. These are 
also identified in the ZTRAX tables as either A for ASCII 
character, N for numeric or D for date. Once these have been 
identified in the specification file the data transfer can begin. 
The FLIMPORT process is an extremely useful tools which saves hours 
of data entry and edit time. Paradox provides documentation in the 
users manual and a FLIMPORT. README file in the main program. Both 
of these sources aid in the construction of a specification file 
and the implementation requirements necessary to run FLIMPORT in 
the desired batch processing mode. 
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VII. MENU HIERARCHY 

The following diagrams of the menu hierarchy will help new users 
to the ZTRAX application navigate their way around the program's 
menu structure. An important note about any menu in ZTRAX or 
Paradox, use the escape key anytime to back up one menu level. If 
you are lost continue to back up the menu chain until you find a 
menu you are familiar with. 



READINESS FLTHRS Leave 











ADD 


f 

EDIT 


VI 


EW 


MANNING 


... 1 .... 

R-LEVELS 


“T 

FLTACT 


1 1 1 

EXHRS CONT PERSTEMPO 



READINESS Menu Structure 
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FLTHRS Menu Structure 
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